As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

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, desde o baixo custo e a baixa complexidade de fazer backups até estratégias mais complexas usando várias regiões ativas. As estratégias ativas/passivas usam um site ativo (como uma região da AWS) para hospedar a carga de trabalho e fornecer tráfego. O site passivo (como uma região diferente da AWS) é usado para recuperação. O site passivo não fornece tráfego ativamente até que um evento de failover seja acionado.

É fundamental avaliar e testar regularmente sua estratégia de recuperação de desastres para que você tenha confiança em invocá-la, caso seja necessário. Use o AWS Resilience Hub para validar e monitorar continuamente a resiliência de suas AWS cargas de trabalho, inclusive se é provável que você atinja suas metas de RTO e RPO.

Figura 6 - Estratégias de recuperação de desastres

Para um evento de desastre baseado na interrupção ou perda de um data center físico para uma carga de trabalho bem arquitetada 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 vai além da interrupção ou perda de um data center físico para a de uma região ou se você estiver sujeito aos requisitos regulatórios que o exijam, considere Pilot Light, Warm Standby ou Multi-Site Active/Active.

Ao escolher sua estratégia e os recursos da AWS para implementá-la, lembre-se de que, dentro da AWS, geralmente dividimos os serviços no plano de dados e no plano de controle. O plano de dados é responsável por prestar serviço em tempo real, enquanto os ambientes de gerenciamento são usados para configurar o ambiente. Para máxima resiliência, você deve usar somente operações de plano de dados como parte de sua operação de failover. Isso ocorre porque os planos de dados normalmente têm metas de projeto de maior disponibilidade do que os planos de controle.

Backup e restauração

O backup e a restauração são uma abordagem adequada para mitigar a perda ou a corrupção de dados. Essa abordagem também pode ser usada para mitigar um desastre regional replicando dados para outras regiões da AWS ou para mitigar a falta de redundância para cargas de trabalho implantadas em uma única zona de disponibilidade. Além dos dados, você deve reimplantar a infraestrutura, a configuração e o código do aplicativo na região de recuperação. Para permitir que a infraestrutura seja reimplantada rapidamente sem erros, você deve sempre implantar usando a infraestrutura como código (IaC) usando serviços como AWS CloudFormationou o. AWS Cloud Development Kit (AWS CDK) Sem o IaC, pode ser complexo restaurar cargas de trabalho na região de recuperação, o que resultará em maiores tempos de recuperação e possivelmente excederá seu RTO. Além dos dados do usuário, certifique-se também de fazer backup do código e da configuração, incluindo Amazon Machine Images (AMIs) que você usa para criar EC2 instâncias da Amazon. Você pode usar AWS CodePipelinepara automatizar a reimplantação do código e da configuração do aplicativo.

Figura 7 - Arquitetura de backup e restauração

Serviços da AWS

Seus dados de carga de trabalho exigirão uma estratégia de backup que seja executada periodicamente ou contínua. A frequência com que você executa o backup determinará seu ponto de recuperação alcançável (que deve se alinhar para atender ao seu RPO). O backup também deve oferecer uma maneira de restaurá-lo até o momento em que foi feito. O backup com point-in-time recuperação está disponível por meio dos seguintes serviços e recursos:

Para o Amazon Simple Storage Service (Amazon S3), você pode usar o Amazon S3 Cross-Region Replication (CRR) para copiar objetos de forma assíncrona para um bucket do S3 na região de DR continuamente, ao mesmo tempo em que fornece versionamento para os objetos armazenados para que você possa escolher seu ponto de restauração. A replicação contínua de dados tem a vantagem de ser o menor tempo (quase zero) para fazer backup de seus dados, mas pode não proteger contra eventos de desastre, como corrupção de dados ou ataques maliciosos (como exclusão não autorizada de dados), bem como backups. point-in-time A replicação contínua é abordada na seção Serviços da AWS para Pilot Light.

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

AWS Backup suporta a cópia de backups entre regiões, como para uma região de recuperação de desastres.

Como uma estratégia adicional de recuperação de desastres para seus dados do Amazon S3, habilite o controle de versão de objetos do S3. O controle de versão de objetos protege seus dados no S3 das consequências das ações de exclusão ou modificação, mantendo a versão original antes da ação. O controle de versão de objetos pode ser uma mitigação útil para desastres do tipo erro humano. Se você estiver usando a replicação do S3 para fazer backup de dados na sua região de DR, então, por padrão, quando um objeto é excluído no bucket de origem, o Amazon S3 adiciona um marcador de exclusão somente no bucket de origem. Essa abordagem protege os dados na região de DR contra exclusões maliciosas 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 carga de trabalho e atingir seu objetivo de tempo de recuperação (RTO). AWS CloudFormationfornece Infraestrutura como Código (IaC) e permite que você defina todos os recursos da AWS em sua carga de trabalho para que você possa implantar e reimplantar de forma confiável em várias contas e regiões da AWS. Você pode fazer backup de EC2 instâncias da Amazon usadas pela sua carga de trabalho como Amazon Machine Images (AMIs). A AMI é criada a partir de instantâneos do volume raiz da sua instância e de quaisquer outros volumes do EBS anexados à sua instância. Você pode usar essa AMI para executar uma versão restaurada da EC2 instância. Uma AMI pode ser copiada dentro ou entre regiões. Ou você pode usar AWS Backuppara copiar backups entre contas e para outras regiões da AWS. O recurso de backup entre contas ajuda a proteger contra eventos de desastres que incluem ameaças internas ou comprometimento da conta. AWS Backup também adiciona recursos adicionais para EC2 backup — além dos volumes individuais do EBS da instância, AWS Backup também armazena e rastreia 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 tags. No entanto, esses metadados adicionais são usados somente ao restaurar o EC2 backup na 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. AWS Backup oferece capacidade de restauração, mas atualmente não permite a restauração programada ou automática. Você pode implementar a restauração automática na região de DR usando o AWS SDK APIs para AWS Backup solicitar. Você pode configurar isso como um trabalho recorrente regular 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 AWS LambdaSNS) e. Implementar uma restauração periódica programada de dados é uma boa ideia, pois a restauração de dados a partir do backup é uma operação do plano de controle. Se essa operação não estivesse disponível durante um desastre, você ainda teria armazenamentos de dados operáveis criados a partir de um backup recente.

Figura 8 - Restaurando e testando backups

Luz piloto

Com a abordagem piloto leve, você replica seus dados de uma região para outra e provisiona uma cópia da sua infraestrutura principal de carga de trabalho. 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 aplicativos, são carregados com o código e as configurações do aplicativo, mas são “desligados” e são usados somente durante testes ou quando o failover de recuperação de desastres é invocado. Na nuvem, você tem a flexibilidade de desprovisionar recursos quando não precisar deles e provisioná-los quando precisar. Uma prática recomendada para “desligado” é não implantar o recurso e, em seguida, criar a configuração e os recursos para implantá-lo (“ativar”) quando necessário. Diferentemente da abordagem de backup e restauração, sua infraestrutura principal está sempre disponível e você sempre tem a opção de provisionar rapidamente um ambiente de produção em grande escala ativando e expandindo seus servidores de aplicativos.

Figura 9: Arquitetura da luz piloto

Uma abordagem piloto leve minimiza o custo contínuo da recuperação de desastres ao minimizar os recursos ativos e simplifica a recuperação no momento de um desastre, pois os principais requisitos de infraestrutura estão todos prontos. 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 na carga de trabalho (configuração, código) simultaneamente em cada região. Essa etapa pode ser simplificada automatizando suas implantações e usando a infraestrutura como código (IaC) para implantar a infraestrutura em várias contas e regiões (implantação completa da infraestrutura na região primária e implantação de infraestrutura reduzida/desativada nas 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 (no caso de credenciais comprometidas também fazerem parte de seus planos de recuperação de desastres).

Com essa abordagem, você também deve evitar um desastre de dados. A replicação contínua de dados protege você contra alguns tipos de desastres, mas pode não protegê-lo contra corrupção ou destruição de dados, a menos que sua estratégia também inclua o controle de versões dos dados armazenados ou opções de recuperação. point-in-time Você pode fazer backup dos dados replicados na região do desastre para criar point-in-time backups nessa mesma região.

Serviços da AWS

Além de usar os serviços da AWS abordados na seção Backup e restauração para criar point-in-time backups, considere também os seguintes serviços para sua estratégia piloto.

Para fins piloto, a replicação contínua de dados em bancos de dados ativos e armazenamentos de dados na região de DR é a melhor abordagem para baixo RPO (quando usada em adição aos point-in-time backups discutidos anteriormente). A AWS fornece replicação de dados assíncrona, contínua e entre regiões para dados usando os seguintes serviços e recursos:

Com a replicação contínua, as versões de seus dados estão 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 dos bancos de dados globais Amazon Aurora.

Ao fazer o failover para executar sua carga de trabalho de leitura/gravação na região de recuperação de desastres, você deve promover uma réplica de leitura do RDS para se tornar 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 banco de dados global Amazon Aurora oferece várias vantagens. O banco de dados global usa uma infraestrutura dedicada que deixa seus bancos de dados totalmente disponíveis para atender seu aplicativo e pode ser replicado para a região secundária com latência típica de menos de um segundo (e dentro de uma região da AWS é muito menos de 100 milissegundos). Com o banco de dados global Amazon Aurora, se sua região principal sofrer uma degradação de desempenho ou uma interrupção, você pode promover que uma das regiões secundárias assuma responsabilidades de leitura/gravação em menos de um minuto, mesmo no caso de uma interrupção regional completa. Você também pode configurar o Aurora para monitorar o tempo de atraso do RPO de todos os clusters secundários para garantir que pelo menos um cluster secundário permaneça dentro da janela de RPO de destino.

Uma versão reduzida de sua infraestrutura principal de carga de trabalho com menos ou menos recursos deve ser implantada em sua região de DR. Usando AWS CloudFormation, você pode definir sua infraestrutura e implantá-la de forma consistente em todas as contas da AWS e em todas as regiões da AWS. AWS CloudFormation usa pseudoparâmetros predefinidos para identificar a conta da AWS e a região da AWS na qual ela está implantada. Portanto, você pode implementar a lógica de condição em seus CloudFormation modelos para implantar somente a versão reduzida de sua infraestrutura na região de DR. Por EC2 exemplo, implantações, uma Amazon Machine Image (AMI) fornece informações como configuração de hardware e software instalado. Você pode implementar um pipeline do Image Builder que cria o que AMIs você precisa e copiá-lo para suas regiões primária e de backup. Isso ajuda a garantir que esses dourados AMIs tenham tudo o que você precisa para reimplantar ou expandir sua carga de trabalho em uma nova região, no caso de um evento de desastre. As EC2 instâncias da Amazon são implantadas em uma configuração reduzida (menos instâncias do que na sua região principal). Para expandir a infraestrutura para suportar o tráfego de produção, consulte Amazon Auto EC2 Scaling na seção Warm Standby.

Para uma configuração ativa/passiva, como luz piloto, todo o tráfego vai inicialmente para a região principal e muda para a região de recuperação de desastres se a região primária não estiver mais disponível. Essa operação de failover pode ser iniciada de forma manual ou automática. O failover iniciado automaticamente com base em verificações de saúde ou alarmes deve ser usado com cautela. Mesmo usando as melhores práticas discutidas aqui, o tempo de recuperação e o ponto de recuperação serão maiores que zero, incorrendo em alguma perda de disponibilidade e de dados. Se você falhar quando não precisar (alarme falso), você incorrerá nessas perdas. 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 AWS os serviços.

Uma opção é usar o Amazon Route 53. Usando o Amazon Route 53, você pode associar vários endpoints IP em uma ou mais regiões da AWS a um nome de domínio do Route 53. Em seguida, você pode rotear o tráfego para o endpoint apropriado sob esse nome de domínio. No failover, você precisa mudar o tráfego para o endpoint de recuperação e para longe do endpoint primário. As verificações de saúde do Amazon Route 53 monitoram esses endpoints. Usando essas verificações de integridade, você pode configurar o failover de DNS iniciado automaticamente para garantir que o tráfego seja enviado somente para endpoints íntegros, o que é uma operação altamente confiável feita no plano de dados. Para implementar isso usando o failover iniciado manualmente, você pode usar o Amazon Application Recovery Controller (ARC). Com o ARC, você pode criar verificações de saúde do Route 53 que, na verdade, não verificam a integridade, mas atuam como interruptores liga/desliga sobre os quais você tem controle total. Usando a AWS CLI ou o AWS SDK, você pode criar um script de failover usando essa API de plano de dados altamente disponível. Seu script ativa essas opções (as verificações de integridade do Route 53) dizendo ao Route 53 que envie tráfego para a região de recuperação em vez da região primária. Outra opção para o failover iniciado manualmente que alguns usaram é usar uma política de roteamento ponderado e alterar os pesos das regiões primária e de recuperação para que todo o tráfego vá para a região de recuperação. No entanto, esteja ciente de que essa é uma operação de plano de controle e, portanto, não é tão resiliente quanto a abordagem do plano de dados usando o Amazon Application Recovery Controller (ARC).

Outra opção é usar AWS Global Accelerator. Usando AnyCast IP, você pode associar vários endpoints em uma ou mais regiões da AWS com o mesmo endereço IP público estático ou endereços. AWS Global Accelerator em seguida, encaminha o tráfego para o endpoint apropriado associado a esse endereço. As verificações de integridade do Global Accelerator monitoram os endpoints. Usando essas verificações de saúde, AWS Global Accelerator verifica a integridade de seus aplicativos e encaminha automaticamente o tráfego do usuário para o endpoint íntegro do aplicativo. Para o failover iniciado manualmente, você pode ajustar qual endpoint recebe tráfego usando discagens de tráfego, mas observe que essa é uma operação de plano de controle. O Global Accelerator oferece latências mais baixas para o endpoint do aplicativo, pois usa a extensa rede de borda da AWS para colocar tráfego no backbone da rede da AWS o mais rápido possível. O Global Accelerator também evita problemas de cache que podem ocorrer com sistemas DNS (como o Route 53).

A Amazon CloudFront oferece failover de origem, em que, se uma determinada solicitação para o endpoint primário falhar, CloudFront encaminha a solicitação para o endpoint secundário. Diferentemente das operações de failover descritas anteriormente, todas as solicitações subsequentes ainda vão para o endpoint primário, e o failover é feito a cada solicitação.

AWS Recuperação flexível de desastres

AWS O Elastic Disaster Recovery (DRS) replica continuamente aplicativos hospedados no servidor e bancos de dados hospedados no servidor de qualquer fonte para AWS usar a replicação em nível de bloco do servidor subjacente. O Elastic Disaster Recovery permite que você use uma região Nuvem AWS como alvo de recuperação de desastres para uma carga de trabalho hospedada localmente ou em outro provedor de nuvem e seu ambiente. Ele também pode ser usado para recuperação de desastres de cargas de trabalho AWS hospedadas se elas consistirem somente em aplicativos e bancos de dados hospedados EC2 (ou seja, não no RDS). O Elastic Disaster Recovery usa a estratégia Pilot Light, mantendo uma cópia dos dados e recursos “desligados” em uma Amazon Virtual Private Cloud (Amazon VPC) usada como área de preparação. Quando um evento de failover é acionado, os recursos em estágios são usados para criar automaticamente uma implantação de capacidade total no Amazon VPC de destino usado como local de recuperação.

Figura 10 - Arquitetura AWS elástica de recuperação de desastres

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. Essa abordagem também permite que você realize testes ou implemente testes contínuos com mais facilidade para aumentar a confiança em sua capacidade de se recuperar de um desastre.

Figura 11 - Arquitetura de espera quente

Nota: Às vezes, a diferença entre a luz piloto e a espera quente pode ser difícil de entender. Ambos incluem um ambiente em sua região de DR com cópias dos ativos de sua região principal. A diferença é que a luz piloto não pode processar solicitações sem que uma ação adicional seja tomada primeiro, enquanto o modo de espera aquecido pode lidar com o tráfego (em níveis de capacidade reduzidos) imediatamente. A abordagem piloto exige que você “ligue” os servidores, possivelmente implante uma infraestrutura adicional (não essencial) e aumente a escala, enquanto o modo de espera aquecido exige apenas que você aumente a escala (tudo já está implantado e em execução). Use suas necessidades de RTO e RPO para ajudá-lo a escolher entre essas abordagens.

Serviços da AWS

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

O Amazon EC2 Auto Scaling é usado para escalar recursos, incluindo EC2 instâncias da Amazon, 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 escala a implantação da EC2 instância em todas as zonas de disponibilidade dentro de uma região da AWS, fornecendo resiliência dentro dessa região. Use o Auto Scaling para expandir sua região de DR até a capacidade total de produção, como parte de uma estratégia piloto de luz ou espera quente. Por exemplo, para EC2, aumente a configuração de capacidade desejada no grupo Auto Scaling. Você pode ajustar essa configuração manualmente por meio do AWS Management Console, automaticamente por meio do AWS SDK ou reimplantando seu AWS CloudFormation modelo usando o novo valor de capacidade desejado. Você pode usar AWS CloudFormation parâmetros para facilitar a reimplantação do CloudFormation modelo. Garanta que as cotas de serviço em sua região de DR estejam definidas como altas o suficiente para não limitar sua escalabilidade até a capacidade de produção.

Como o Auto Scaling é uma atividade do plano de controle, depender dela diminuirá a resiliência de sua estratégia geral de recuperação. É uma troca. Você pode optar por provisionar capacidade suficiente para que a região de recuperação possa lidar com toda a carga de produção conforme implantada. Essa configuração estaticamente estável é chamada de hot standby (consulte a próxima seção). Ou você pode optar por provisionar menos recursos, o que custará menos, mas depender do Auto Scaling. Algumas implementações de DR implantarão recursos suficientes para lidar com o tráfego inicial, garantindo um baixo RTO e, em seguida, confiarão no Auto Scaling para acelerar o tráfego subsequente.

Multissite ativa/ativa

Você pode executar sua carga de trabalho simultaneamente em várias regiões como parte de uma estratégia ativa/ativa de vários sites ou ativa/passiva em espera ativa. Vários sites. active/active serves traffic from all regions to which it is deployed, whereas hot standby serves traffic only from a single region, and the other Region(s) are only used for disaster recovery. With a multi-site active/active approach, users are able to access your workload in any of the Regions in which it is deployed. This approach is the most complex and costly approach to disaster recovery, but it can reduce your recovery time to near zero for most disasters with the correct technology choices and implementation (however data corruption may need to rely on backups, which usually results in a non-zero recovery point). Hot standby uses an active/passive configuration where users are only directed to a single region and DR regions do not take traffic. Most customers find that if they are going to stand up a full environment in the second Region, it makes sense to use it active/active Como alternativa, se você não quiser usar as duas regiões para lidar com o tráfego de usuários, o Warm Standby oferece uma abordagem mais econômica e operacionalmente menos complexa.

Figura 12 - Arquitetura ativa/ativa de vários sites (altere um caminho ativo para inativo para hot standby)

Com a necessidade de uma abordagem de vários locais active/active, because the workload is running in more than one Region, there is no such thing as failover in this scenario. Disaster recovery testing in this case would focus on how the workload reacts to loss of a Region: Is traffic routed away from the failed Region? Can the other Region(s) handle all the traffic? Testing for a data disaster is also required. Backup and recovery are still required and should be tested regularly. It should also be noted that recovery times for a data disaster involving data corruption, deletion, or obfuscation will always be greater than zero and the recovery point will always be at some point before the disaster was discovered. If the additional complexity and cost of a multi-site active/active (ou de espera ativa) para manter tempos de recuperação quase nulos, esforços adicionais devem ser feitos para manter a segurança e evitar erros humanos para mitigar os desastres humanos.

Serviços da AWS

Todos os serviços da AWS cobertos por backup e restauração, iluminação piloto e espera quente também são usados aqui para backup de dados, replicação de point-in-time dados, roteamento de tráfego ativo/ativo e implantação e escalabilidade da infraestrutura, incluindo instâncias. EC2

Para os cenários ativos/passivos discutidos anteriormente (Pilot Light e Warm Standby), tanto o Amazon Route 53 quanto o Amazon AWS Global Accelerator podem ser usados para rotear o tráfego da rede para a região ativa. Para a estratégia ativa/ativa aqui, esses dois serviços também permitem a definição de políticas que determinam quais usuários acessam qual endpoint regional ativo. Com AWS Global Accelerator você define uma discagem de tráfego para controlar a porcentagem de tráfego que é direcionada para cada endpoint do aplicativo. O Amazon Route 53 suporta essa abordagem percentual e também várias outras políticas disponíveis, incluindo políticas baseadas em geoproximidade e latência. O Global Accelerator aproveita automaticamente a extensa rede de servidores de borda da AWS para integrar o tráfego ao backbone da rede da AWS o mais rápido possível, resultando em menores latências de solicitação.

A replicação assíncrona de dados com essa estratégia permite um RPO quase zero. Os serviços da AWS, como o banco de dados global Amazon Aurora, usam uma infraestrutura dedicada que deixa seus bancos de dados totalmente disponíveis para atender seu aplicativo e podem ser replicados em até cinco regiões secundárias com latência típica de menos de um segundo. With active/passive strategies, writes occur only to the primary Region. The difference with active/active está projetando como a consistência dos dados com gravações em cada região ativa é tratada. É comum projetar leituras de usuários para serem atendidas na região mais próxima a eles, conhecida como leitura local. Com as gravações, você tem várias opções:

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