Opções de recuperação de desastres na nuvem

As estratégias de recuperação de desastres disponíveis para você na AWS podem ser amplamente categorizadas em quatro abordagens, que vão desde baixo custo e baixa complexidade para fazer backups a estratégias mais complexas que envolvem o uso de várias regiões ativas. É fundamental testar regularmente sua estratégia de recuperação de desastres para que tenha confiança em invocá-la caso seja necessário.

Figura 6: estratégias de recuperação de desastres

Para um evento de desastre que envolva interrupção ou perda de um único datacenter físico para uma workload bem projetada e altamente disponível, você pode precisar apenas de uma abordagem de backup e restauração para a recuperação de desastres. Se sua definição de desastre for além da interrupção ou perda de um datacenter físico, mas de uma região, ou se você estiver sujeito a requisitos regulatórios que exijam uma estratégia, considere o modo luz piloto, standby passivo ou ativo/ativo em vários locais.

Backup e restauração

Backup e restauração são uma abordagem adequada para atenuar a perda ou corrupção de dados. Essa abordagem também pode ser usada para mitigar um desastre regional por meio da replicação de dados para outras regiões da AWS ou para atenuar a falta de redundância para workloads implantadas em uma única zona de disponibilidade. Além dos dados, você deve reimplantar a infraestrutura, a configuração e o código da aplicação na região de recuperação. Para permitir que a infraestrutura seja reimplantada rapidamente sem erros, você deve sempre utilizar a infraestrutura como código (IaC) na implantação usando serviços como o AWS CloudFormation ou o AWS Cloud Development Kit (AWS CDK). Sem a IaC, pode ser difícil restaurar workloads na região de recuperação. Com isso, você pode ter tempos de recuperação maiores e, possivelmente, ultrapassar seu RTO. Além dos dados do usuário, você também deve fazer backup do código e da configuração, bem como das imagens de máquina da Amazon (AMIs) usadas para criar instâncias do Amazon EC2. Você pode usar o AWS CodePipeline para automatizar a reimplantação do código e da configuração da aplicação.

Figura 7: arquitetura de backup e restauração

Serviços da AWS

Os dados da workload exigirão uma estratégia de backup que seja executada periodicamente ou seja contínua. A frequência com que você executa o backup determinará o ponto de recuperação alcançável (que deve estar alinhado para atender ao seu RPO). O backup também deve oferecer um meio para ser restaurado até o ponto em que foi realizado. O backup com recuperação em um ponto anterior no tempo é disponibilizado por meio dos seguintes serviços e recursos:

• Snapshot do Amazon Elastic Block Store (Amazon EBS)

• Backup do Amazon DynamoDB

• Snapshot do Amazon RDS

• Snapshot do banco de dados do Amazon Aurora

• Backup do Amazon EFS (ao usar o AWS Backup)

• Snapshot do Amazon Redshift

• Snapshot do Amazon Neptune

Para o Amazon Simple Storage Service (Amazon S3), você pode usar a replicação entre regiões (CRR) do Amazon S3 para copiar objetos continuamente de forma assíncrona para um bucket do S3 na região de DR e, ao mesmo tempo, fornecer versionamento para os objetos armazenados para que possa escolher o ponto de restauração. A replicação contínua de dados tem a vantagem de oferecer o menor tempo de backup (quase zero), mas pode não oferecer proteção contra eventos de desastre, como corrupção de dados ou ataques mal-intencionados (por exemplo, exclusão não autorizada de dados), bem como backups em um ponto anterior no tempo. A replicação contínua é abordada na seção Serviços da AWS para luz piloto.

O AWS Backup fornece um local centralizado para configurar, programar e monitorar os recursos de backup da AWS para os seguintes serviços e recursos:

• Volumes do Amazon Elastic Block Store (Amazon EBS)

• Instâncias do Amazon EC2

• Bancos de dados do Amazon Relational Database Service (Amazon RDS) (incluindo bancos de dados do Amazon Aurora)

• Tabelas do Amazon DynamoDB

• Sistemas de arquivos do Amazon Elastic File System (Amazon EFS)

• Volumes do AWS Storage Gateway

• Amazon FSx for Windows File Server e Amazon FSx for Lustre

Com o AWS Backup, é possível fazer cópia de backups entre regiões; por exemplo, para uma região de recuperação de desastres.

Para ter outra estratégia de recuperação de desastres para seus dados do Amazon S3, habilite o versionamento de objetos do S3. O versionamento de objetos protege seus dados no S3 contra as consequências das ações de exclusão ou modificação, mantendo a versão original antes da ação. O versionamento de objetos pode ser um método útil para atenuar desastres provocados por erros humanos. Se você estiver usando a replicação do S3 para fazer backup de dados em sua região de DR, quando um objeto for excluído no bucket de origem, o Amazon S3 adicionará um marcador de exclusão somente no bucket de origem por padrão. Essa abordagem protege os dados na região de DR contra exclusões mal-intencionadas na região de origem.

Além dos dados, você também deve fazer backup da configuração e da infraestrutura necessárias para reimplantar sua workload e atender ao objetivo de tempo de recuperação (RTO). O AWS CloudFormation fornece infraestrutura como código (IaC) e permite que você defina todos os recursos da AWS em sua workload para que possa realizar implantações e reimplantações de forma confiável em várias contas e regiões da AWS. Você pode fazer backup das instâncias do Amazon EC2 usadas por sua workload como imagens de máquina da Amazon (AMIs). A AMI é criada de snapshots do volume raiz da instância e de quaisquer outros volumes do EBS anexados à instância. Você pode usar essa AMI para executar uma versão restaurada da instância do EC2. É possível copiar uma AMI dentro ou entre regiões. Ou você pode usar o AWS Backup para copiar backups entre contas e para outras regiões da AWS. O recurso de backup entre contas ajuda a oferecer proteção contra eventos de desastres que incluem ameaças internas ou comprometimento da conta. O AWS Backup também adiciona outros recursos para backup do EC2, além dos volumes individuais do EBS da instância. Além disso, o AWS Backup armazena e monitora os seguintes metadados: tipo de instância, nuvem privada virtual (VPC) configurada, grupo de segurança, função do IAM, configuração de monitoramento e etiquetas. No entanto, esses metadados adicionais só são usados na restauração do backup do EC2 para a mesma região da AWS.

Todos os dados armazenados na região de recuperação de desastres como backups devem ser restaurados no momento do failover. O AWS Backup oferece recurso de restauração, mas atualmente não permite restauração programada ou automática. Você pode implementar a restauração automática para a região de DR usando o AWS SDK para chamar APIs para o AWS Backup. Você pode definir essa configuração como um trabalho regularmente recorrente ou acionar a restauração sempre que um backup for concluído. A figura a seguir mostra um exemplo de restauração automática usando o Amazon Simple Notification Service (Amazon SNS) e o AWS Lambda.

Figura 8: restauração e teste de backups

nota

Sua estratégia de backup deve incluir o teste de seus backups. Consulte a seção Testes de recuperação de desastres para obter mais informações. Consulte AWS Well-Architected Lab: Testing Backup and Restore of Data para obter uma demonstração prática da implementação.

Luz piloto

Com a abordagem de luz piloto, você replica seus dados de uma região para outra e provisiona uma cópia de sua infraestrutura de workload principal. Os recursos necessários para auxiliar a replicação e o backup de dados, como bancos de dados e armazenamento de objetos, estão sempre ativos. Outros elementos, como servidores de aplicações, são carregados com o código e as configurações da aplicação, mas são desativados e usados apenas durante testes ou quando o failover de recuperação de desastres é invocado. Ao contrário da abordagem de backup e restauração, sua infraestrutura principal está constantemente disponível e você sempre tem a opção de provisionar rapidamente um ambiente de produção em grande escala ativando e aumentando a escala na horizontal dos servidores de aplicações.

Figura 9: arquitetura de luz piloto

A abordagem de luz piloto reduz o custo contínuo da recuperação de desastres ao minimizar os recursos ativos e simplifica a recuperação no momento de um desastre porque todos os principais requisitos de infraestrutura estão em ordem. Essa opção de recuperação exige que você altere sua abordagem de implantação. Você precisa fazer alterações na infraestrutura principal em cada região e implantar alterações de workload (configuração, código) simultaneamente em cada região. Para simplificar essa etapa, você pode automatizar suas implantações e usar a infraestrutura como código (IaC) para implantar infraestrutura em várias contas e regiões (implantação completa da infraestrutura na região principal e implantação de infraestrutura reduzida na escala vertical/desativada para regiões de DR). É recomendável usar uma conta diferente por região para fornecer o mais alto nível de isolamento de recursos e segurança (caso seus planos de recuperação de desastres também incluam credenciais comprometidas).

Com essa abordagem, você também precisa atenuar desastres de dados. A replicação contínua de dados protege você contra alguns tipos de desastre, mas pode não oferecer proteção contra corrupção ou destruição de dados, a menos que sua estratégia também inclua versionamento de dados armazenados ou opções para recuperação em um ponto anterior no tempo. Você pode fazer backup dos dados replicados na região do desastre para criar backups em um ponto anterior no tempo nessa mesma região.

Serviços da AWS

Além de usar os serviços da AWS abordados na seçãoBackup e restauração para criar backups em um ponto anterior no tempo, considere também os seguintes serviços para sua estratégia de luz piloto.

Com relação à luz piloto, a replicação contínua de dados para bancos de dados e armazenamentos de dados em tempo real na região de DR é a melhor abordagem para RPO baixo (quando usada além dos backups em um ponto anterior no tempo discutidos anteriormente). A AWS fornece replicação de dados contínua, entre regiões e assíncrona para dados por meio dos seguintes serviços e recursos:

• Replicação do Amazon Simple Storage Service (Amazon S3)

• Réplicas de leitura do Amazon RDS

• Amazon Aurora Global Database

• Tabelas globais do Amazon DynamoDB

Com a replicação contínua, as versões de seus dados ficam disponíveis quase imediatamente em sua região de DR. Os tempos reais de replicação podem ser monitorados usando recursos de serviço como o S3 Replication Time Control (S3 RTC) para objetos do S3 e recursos de gerenciamento do Amazon Aurora Global Database.

Ao fazer o failover para executar sua workload de leitura e gravação na região de recuperação de desastres, você deve promover uma réplica de leitura do RDS para que se torne a instância primária. Para instâncias de banco de dados diferentes do Aurora, o processo leva alguns minutos para ser concluído e a reinicialização faz parte do processo. Para replicação entre regiões (CRR) e failover com o RDS, o uso do Amazon Aurora Global Database oferece várias vantagens. O banco de dados global usa uma infraestrutura dedicada que mantém seus bancos de dados totalmente disponíveis para atender à sua aplicação e pode replicar para a região secundária com latência típica de menos de 1 segundo (e com uma latência bem menor que 100 milissegundos dentro de uma região da AWS). Com o Amazon Aurora Global Database, se sua região principal sofrer uma degradação de performance ou interrupção, você poderá promover uma das regiões secundárias para assumir responsabilidades de leitura/gravação em menos de 1 minuto, mesmo no caso de uma paralisação regional completa. A promoção pode ser automática e não há reinicialização.

Uma versão de sua infraestrutura de workload principal reduzida na escala vertical, com menos recursos ou recursos menores, deve ser implantada em sua região de DR. Usando o AWS CloudFormation, você pode definir sua infraestrutura e implantá-la de forma consistente nas contas e regiões da AWS. O AWS CloudFormation usa pseudoparâmetros predefinidos para identificar a conta da AWS e a região da AWS em que ela está implantada. Portanto, você pode implementar a lógica de condição em seus modelos do CloudFormation para implantar na região de recuperação de desastres somente a versão de sua infraestrutura reduzida na escala vertical. Para implantações de instâncias do EC2, uma imagem de máquina da Amazon (AMI) fornece informações como configuração de hardware e software instalado. Você pode implementar um pipeline do Image Builder que cria as AMIs necessárias e copiá-las para as regiões principal e de backup. Isso ajuda a garantir que essas AMIs ouro tenham tudo o que você precisa para reimplantar ou expandir sua workload em uma nova região em caso de desastre. As instâncias do Amazon EC2 são implantadas em uma configuração reduzida na escala vertical (menos instâncias do que em sua região principal). Você pode usar o hibernate para colocar instâncias do EC2 em um estado interrompido, no qual você não paga pelos custos do EC2, mas apenas pelo armazenamento usado. Para iniciar instâncias do EC2, você pode criar scripts usando a Command Line Interface (AWS CLI) ou o AWS SDK. Para dimensionar a infraestrutura para comportar o tráfego de produção, consulte AWS Auto Scaling na seção Standby passivo.

Para uma configuração ativo/standby, como a luz piloto, a princípio todo tráfego vai para a região principal e muda para a região de recuperação de desastres se a região principal não estiver mais disponível. Há duas opções de gerenciamento de tráfego a serem consideradas ao usar os serviços da AWS. A primeira é usar o Amazon Route 53. Com 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. Em seguida, você pode encaminhar o tráfego para o endpoint apropriado com esse nome de domínio. As verificações de integridade do Amazon Route 53 monitoram esses endpoints. Usando essas verificações de integridade, você pode configurar o failover de DNS para garantir que o tráfego seja enviado para endpoints íntegros.

A segunda opção é usar o AWS Global Accelerator. Usando o AnyCast IP, você pode associar vários endpoints em uma ou mais regiões da AWS com o(s) mesmo(s) endereço(s) IP estático(s). Em seguida, o AWS Global Accelerator encaminha o tráfego para o devido endpoint associado a esse endereço. As verificações de integridade do Global Accelerator monitoram endpoints. Usando essas verificações de integridade, o AWS Global Accelerator verifica automaticamente a integridade de suas aplicações e encaminha o tráfego do usuário somente para um endpoint íntegro da aplicação. O Global Accelerator oferece latências mais baixas para o endpoint da aplicação, pois utiliza a extensa rede de borda da AWS para introduzir o tráfego na estrutura da rede da AWS o mais rápido possível. O Global Accelerator também evita problemas de armazenamento em cache que podem ocorrer com sistemas DNS (como o Route 53).

CloudEndure Disaster Recovery

O CloudEndure Disaster Recovery, disponível no AWS Marketplace, replica continuamente para a AWS as aplicações hospedadas em servidor e os bancos de dados hospedados em servidor de qualquer origem usando replicação em nível de bloco do servidor subjacente. O CloudEndure Disaster Recovery permite que você use a Nuvem AWS como uma região de recuperação de desastres para uma workload on-premises e o respectivo ambiente. Ele também pode ser usado para recuperação de desastres de workloads hospedadas na AWS se elas consistirem apenas em aplicações e bancos de dados hospedados no EC2 (ou seja, não no RDS). O CloudEndure Disaster Recovery usa a estratégia de luz piloto e mantém uma cópia de dados e recursos desativados em uma Amazon Virtual Private Cloud (Amazon VPC) usada como área de preparação. Quando um evento de failover é acionado, os recursos preparados são usados para criar automaticamente uma implantação de capacidade total na Amazon VPC de destino usada como local de recuperação.

Figura 10: arquitetura do CloudEndure Disaster Recovery

Standby passivo

Na abordagem de standby passivo, é necessário garantir que haja uma cópia reduzida na escala vertical, mas totalmente funcional, de seu ambiente de produção em outra região. Essa abordagem amplia o conceito de luz piloto e diminui o tempo de recuperação porque sua workload fica sempre ativa em outra região. Ela também permite que você realize testes com maior facilidade ou implemente testes contínuos para aumentar a confiança em sua capacidade de se recuperar de um desastre.

Figura 11: arquitetura de standby passivo

Observação: a diferença entre luz piloto e standby passivo às vezes pode ser difícil de entender. Ambos incluem um ambiente em sua região de DR com cópias dos principais ativos da região. A diferença é que a luz piloto não pode processar solicitações sem que outras ações sejam executadas primeiro, enquanto o modo de standby passivo pode lidar imediatamente com o tráfego (em níveis de capacidade reduzidos). A abordagem de luz piloto requer que você “ligue” os servidores, possivelmente implante infraestrutura adicional (não central) e aumente a escala na vertical, enquanto o modo de standby passivo requer apenas que você aumente a escala na vertical (tudo já está implantado e em execução). Use suas necessidades de RTO e RPO para ajudar você a escolher uma dessas abordagens.

Serviços da AWS

Todos os serviços da AWS cobertos por backup e restauração e luz piloto também são usados em standby para backup de dados, replicação de dados, roteamento de tráfego ativo/standby e implantação de infraestrutura que inclui instâncias do EC2.

O AWS Auto Scaling é usado para escalar recursos, incluindo instâncias do Amazon EC2, tarefas do Amazon ECS, taxa de transferência do Amazon DynamoDB e réplicas do Amazon Aurora em uma região da AWS. O Amazon EC2 Auto Scaling dimensiona escala a implantação da instância do EC2 nas zonas de disponibilidade dentro de uma região da AWS, fornecendo resiliência dentro dessa região. Como parte de uma estratégia de luz piloto ou standby passivo, use o Auto Scaling para aumentar a escala de sua região de DR na horizontal para a capacidade total de produção. Por exemplo, para o EC2, aumente a configuração da capacidade desejada no grupo do Auto Scaling. Você pode ajustar essa configuração manualmente por meio do AWS Management Console, automaticamente por meio do AWS SDK ou reimplantando seu modelo do AWS CloudFormation usando o novo valor de capacidade desejada. Você pode usar parâmetros do AWS CloudFormation para facilitar a reimplantação do modelo do CloudFormation. Defina as cotas de serviço em sua região de DR com um valor alto o suficiente para não impedir que você aumente a escala na vertical para a capacidade de produção.

Ativo/ativo em vários locais

Você pode executar sua workload simultaneamente em várias regiões como parte de uma estratégia ativo/ativo em vários locais ou de standby a quente ativo/passivo. A estratégia ativo/ativo em vários locais atende ao tráfego de todas as regiões nas quais está implantada, enquanto o standby a quente atende ao tráfego apenas de uma região, e as outras regiões são usadas somente para recuperação de desastres. Com uma abordagem ativo/ativo em vários locais, os usuários podem acessar sua workload em qualquer uma das regiões em que ela está implantada. Essa é a abordagem mais complexa e cara para a recuperação de desastres, mas pode reduzir o tempo de recuperação para quase zero na maioria dos desastres com as opções de tecnologia e implementação corretas (no entanto, a corrupção de dados pode precisar contar com backups, o que geralmente resulta em um ponto de recuperação diferente de zero). O standby a quente usa uma configuração ativo/passivo em que os usuários são direcionados apenas para uma região e as regiões de DR não recebem tráfego. A maioria dos clientes acredita que, se eles forem criar um ambiente completo na segunda região, faz sentido usá-lo como ativo/ativo. Entretanto, se você não quiser usar as duas regiões para lidar com o tráfego do usuário, o modo de stanby a quente é uma abordagem mais econômica e menos complexa do ponto de vista operacional.

Figura 12: arquitetura ativa/ativa em vários locais (altere um caminho ativo para Inativo para standby a quente)

No cenário ativo/ativo em vários locais, visto que a workload está sendo executada em mais de uma região, não existe failover. Nesse caso, o teste de recuperação de desastres se concentraria em como a workload reage à perda de uma região: o tráfego é encaminhado para fora da região com falha? As outras regiões podem lidar com todo o tráfego? Também é necessário testar um desastre de dados. O backup e a recuperação ainda assim são necessários e devem ser testados regularmente. Também é necessário observar que os tempos de recuperação de um desastre de dados envolvendo corrupção, exclusão ou obscurecimento de dados sempre serão superiores a zero e o ponto de recuperação sempre estará em algum ponto antes da descoberta do desastre. Se a complexidade e custo adicionais de uma abordagem ativo/ativo em vários locais (ou standby a quente) forem necessários para manter tempos de recuperação quase nulos, outros esforços deverão ser feitos para preservar a segurança, bem como evitar erros humanos e atenuar desastres humanos.

Serviços da AWS

Todos os serviços da AWS cobertos por backup e restauração, luz piloto e standby passivo também são usados aqui para backup de dados em um ponto anterior no tempo, replicação de dados, roteamento de tráfego ativo/ativo e implantação e escalabilidade de infraestrutura que inclui instâncias do EC2.

Para os cenários ativo/passivo discutidos anteriormente (luz piloto e standby passivo), o Amazon Route 53 e o AWS Global Accelerator podem ser usados para encaminhar o tráfego de rede para a região ativa. Aqui, para a estratégia ativo/ativo, esses dois serviços também permitem a definição de políticas que determinam quais usuários irão para qual endpoint regional ativo. Com o AWS Global Accelerator, você define uma discagem de tráfego para controlar a porcentagem de tráfego que é direcionada para cada endpoint da aplicação. O Amazon Route 53 comporta essa abordagem de porcentagem e também várias outras políticas disponíveis, inclusive aquelas baseadas em geoproximidade e latência. O Global Accelerator utiliza automaticamente a extensa rede de servidores de borda da AWS para introduzir o tráfego na estrutura de rede da AWS o mais rápido possível, o que resulta em latências de solicitação mais baixas.

A replicação de dados com essa estratégia permite um RPO próximo de zero. Serviços da AWS como o Amazon Aurora Global Database usam uma infraestrutura dedicada que mantém seus bancos de dados totalmente disponíveis para atender à sua aplicação e podem realizar a replicação para uma região secundária com latência típica de menos de um segundo. Com as estratégias ativo/passivo, as gravações ocorrem somente na região primária. Na estratégia ativo/ativo, a diferença é delinear de que forma as gravações em cada região ativa serão tratadas. As leituras do usuário normalmente são projetadas para que sejam realizadas na região mais próxima a eles, o que é conhecido como leitura local. Nas gravações, você tem várias opções:

• Na estratégia de gravação global, todas as gravações são encaminhadas para uma única região. Em caso de falha nessa região, outra região é promovida para aceitar gravações. O Aurora Global Datase é uma boa opção para gravação global porque comporta sincronização com réplicas de leitura entre regiões e você pode promover uma das regiões secundárias para assumir responsabilidades de leitura/gravação em menos de 1 minuto.

• Na estratégia de gravação local, as gravações são encaminhadas para a região mais próxima (assim como as leituras). As tabelas globais do Amazon DynamoDB possibilitam essa estratégia, permitindo leituras e gravações de todas as regiões em que sua tabela global estiver implantada. As tabelas globais do Amazon DynamoDB usam a reconciliação último gravador ganha entre as atualizações simultâneas.

• Na estratégia de gravação particionada, as gravações são atribuídas a uma região específica com base em uma chave de partição (como ID de usuário) para evitar conflitos de gravação. A replicação do Amazon S3 configurada bidirecionalmente pode ser usada para esse caso e, no momento, comporta replicação entre duas regiões. Ao implementar essa abordagem, habilite a sincronização de modificação de réplica nos buckets A e B para replicar alterações de metadados de réplica como listas de controle de acesso a objetos (ACLs), etiquetas de objeto ou bloqueios de objeto nos objetos replicados. Você também pode configurar se deve ou não replicar marcadores de exclusão entre buckets em suas regiões ativas. Além da replicação, sua estratégia também deve incluir backups em um ponto anterior no tempo como proteção contra eventos de corrupção ou destruição de dados.

O AWS CloudFormation é uma ferramenta avançada para aplicar a infraestrutura implantada de forma consistente entre contas da AWS em várias regiões da AWS. O AWS CloudFormation StackSets amplia essa funcionalidade ao permitir que você crie, atualize ou exclua pilhas do CloudFormation em várias contas e regiões com uma única operação. Embora o AWS CloudFormation use YAML ou JSON para definir a infraestrutura como código, o AWS Cloud Development Kit (AWS CDK) permite que você defina a IaC usando linguagens de programação conhecidas. Seu código é convertido para o CloudFormation, que é usado para implantar recursos na AWS.