Selecione suas preferências de cookies

Usamos cookies essenciais e ferramentas semelhantes que são necessárias para fornecer nosso site e serviços. Usamos cookies de desempenho para coletar estatísticas anônimas, para que possamos entender como os clientes usam nosso site e fazer as devidas melhorias. Cookies essenciais não podem ser desativados, mas você pode clicar em “Personalizar” ou “Recusar” para recusar cookies de desempenho.

Se você concordar, a AWS e terceiros aprovados também usarão cookies para fornecer recursos úteis do site, lembrar suas preferências e exibir conteúdo relevante, incluindo publicidade relevante. Para aceitar ou recusar todos os cookies não essenciais, clique em “Aceitar” ou “Recusar”. Para fazer escolhas mais detalhadas, clique em “Personalizar”.

DR para workloads nativos de nuvem

Modo de foco
DR para workloads nativos de nuvem - AWS Orientação prescritiva

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á.

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á.

Considere como suas cargas de trabalho nativas da nuvem se alinham aos seus objetivos de DR. AWS fornece várias zonas de disponibilidade em regiões ao redor do mundo. Muitas empresas que utilizam a nuvem AWS alinham suas arquiteturas de workload e objetivos de DR para suportar a perda de uma zona de disponibilidade. O pilar de confiabilidade no AWS Well-Architected Framework apóia essa melhor prática. Você pode arquitetar seus workload e suas dependências de serviços e aplicativos para usar várias zonas de disponibilidade. Você pode então automatizar sua DR e atingir seus objetivos de DR com mínima ou nenhuma intervenção.

Na prática, no entanto, você pode descobrir que não consegue estabelecer uma arquitetura redundante, ativa e automatizada para todos os seus componentes. Examine cada camada de sua arquitetura para determinar os processos de DR necessários para atingir seus objetivos. Isso pode variar de workload para workload, com diferentes requisitos de arquitetura e serviço. Este guia aborda considerações e opções para a Amazon EC2. Para outros serviços AWS , você pode consultar a AWS documentação para determinar a alta disponibilidade e as opções de DR.

DR para Amazon EC2 em uma única zona de disponibilidade

Tente arquitetar seu workload para oferecer suporte e atender ativamente clientes de várias zonas de disponibilidade. Você pode usar o Amazon EC2 Auto Scaling e o Elastic Load Balancing para obter uma arquitetura de servidor Multi-AZ para a Amazon EC2 e outros serviços.

Se sua arquitetura tiver EC2 instâncias que não podem ter balanceamento de carga e só podem ter uma única instância em execução a qualquer momento, você pode usar uma das opções a seguir.

  • Crie um grupo do Auto Scaling que tenha os tamanhos mínimo, máximo e desejado de 1 e esteja configurado para várias zonas de disponibilidade. Crie uma AMI que possa ser usada para substituir a instância se ela falhar. Certifique-se de definir a automação e a configuração adequadas para que uma instância recém-provisionada da AMI possa ser configurada automaticamente e fornecer serviços. Crie um balanceador de carga que aponte para o grupo do Auto Scaling e esteja configurado para várias zonas de disponibilidade. Opcionalmente, crie um alias do Amazon Route 53 que aponte para o endpoint do balanceador de carga.

  • Crie um registro do Route 53 para sua instância ativa e faça com que seus clientes se conectem usando esse registro. Crie um script que crie uma nova AMI da sua instância ativa e use a AMI para provisionar uma nova EC2 instância no estado interrompido em uma zona de disponibilidade separada. Configure o script para ser executado periodicamente e encerrar a instância interrompida anterior. Se houver uma falha na zona de disponibilidade, inicie sua instância de backup na zona de disponibilidade alternativa. Em seguida, atualize o registro do Route 53 para apontar para essa nova instância.

Teste sua solução minuciosamente simulando a falha contra a qual a solução foi projetada para proteger. Considere também as atualizações que sua solução de DR precisará à medida que sua arquitetura de workload mudar.

DR para a Amazon EC2 em uma falha regional

Clientes com requisitos de disponibilidade muito altos (por exemplo, aplicativos de missão crítica que não toleram nenhum tempo de inatividade) podem usar AWS em várias regiões para fornecer maior resiliência contra problemas em nível regional. Os clientes devem avaliar cuidadosamente a complexidade, o custo e o esforço necessários para estabelecer e manter um plano de DR multirregional em relação ao benefício. AWS fornece recursos que oferecem suporte a arquiteturas multirregionais para disponibilidade global, failover e DR. Este guia aborda alguns dos recursos disponíveis que são específicos para backup e recuperação na Amazon. EC2

AWS AMIs e os snapshots do Amazon EBS são recursos regionais que podem ser usados para provisionar novas instâncias em uma única região. No entanto, você pode copiar seus snapshots AMIs para outra região e usá-los para provisionar novas instâncias nessa região. Para dar suporte a um plano regional de recuperação de desastres para falhas, você pode automatizar o processo de cópia AMIs e captura de instantâneos para outras regiões. AWS Backup e o Amazon Data Lifecycle Manager oferecem suporte à cópia entre regiões como parte de sua configuração de backup.

AWS Elastic Disaster Recoverypode ser usado para automatizar e replicar continuamente EC2 seus servidores da Amazon em uma região para uma região alternativa de DR. O Elastic Disaster Recovery pode simplificar sua abordagem de DR em várias regiões e ajudá-lo a testar regularmente seu plano de EC2 DR entre regiões da Amazon usando simulações. A recuperação de desastres elástica pode ajudar quando o backup e a recuperação não conseguirem atingir seus objetivos de RTO e RPO. A recuperação de desastres elástica pode ajudá-lo a reduzir seu RTO para minutos e seu RPO para uma faixa de menos de um segundo.

Qualquer que seja a solução utilizada, você deve determinar o processo de provisionamento, failover e failback a ser usado no caso de uma interrupção. Você pode utilizar o Route 53 com verificação de integridade e failover do Sistema de Nomes de Domínio para ajudar a oferecer suporte à sua solução.

PrivacidadeTermos do sitePreferências de cookies
© 2025, Amazon Web Services, Inc. ou suas afiliadas. Todos os direitos reservados.