# Confiabilidade
O pilar Confiabilidade abrange a capacidade de uma workload de executar a função pretendida correta e consistentemente quando esperado. Isso inclui a capacidade de operar e testar a workload durante todo o ciclo de vida dela. Este documento fornece orientações detalhadas sobre as práticas recomendadas para a implementação de workloads confiáveis na AWS.
**Topics**
+ [
# Modelo de responsabilidade compartilhada para resiliência
](shared-responsibility-model-for-resiliency.md)
+ [
# Princípios de design
](design-principles.md)
+ [
# Definições
](definitions.md)
+ [
# Como entender as necessidades de disponibilidade
](understanding-availability-needs.md)
# Modelo de responsabilidade compartilhada para resiliência
A resiliência é uma responsabilidade compartilhada entre você e a AWS. É importante entender como a recuperação de desastres (DR) e a disponibilidade, como parte da resiliência, operam nesse modelo compartilhado.
**Responsabilidade da AWS: resiliência da nuvem**
A AWS é responsável pela resiliência da infraestrutura que executa todos os serviços oferecidos na Nuvem AWS. Essa infraestrutura é composta por hardware, software, redes e instalações que executam os serviços da Nuvem AWS. A AWS emprega esforços comercialmente razoáveis para disponibilizar esses serviços da Nuvem AWS, garantindo que a disponibilidade do serviço atenda ou exceda os [acordos de nível de serviço (SLAs) da AWS](https://aws.amazon.com/legal/service-level-agreements/).
A [infraestrutura de nuvem global da AWS](https://aws.amazon.com/about-aws/global-infrastructure/) foi projetada para permitir que os clientes criem arquiteturas de workload altamente resilientes. Cada Região da AWS é totalmente isolada e composta de várias [zonas de disponibilidade](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/#Availability_Zones), que são partições de infraestrutura fisicamente isoladas umas das outras. As zonas de disponibilidade isolam falhas que poderiam afetar a resiliência da workload, impedindo que elas afetem outras zonas na região. No entanto, ao mesmo tempo, todas as zonas em uma Região da AWS são interconectadas com rede de alta largura de banda e baixa latência, por fibra metropolitana dedicada totalmente redundante, fornecendo conexão de rede com alto throughput e baixa latência entre as zonas. Todo o tráfego entre as zonas é criptografado. A performance da rede é suficiente para realizar a replicação síncrona entre as zonas. Quando uma aplicação é particionada entre AZs, as empresas permanecem mais bem isoladas e protegidas contra problemas como queda de energia, raios, tornados, furacões, entre outros.
**Responsabilidade do cliente: resiliência na nuvem**
Sua responsabilidade é determinada pelos serviços da Nuvem AWS que você escolhe. Isso determina o volume do trabalho de configuração que você deve executar como parte das suas responsabilidades de resiliência. Por exemplo, um serviço como o Amazon Elastic Compute Cloud (Amazon EC2) exige que o cliente realize todas as tarefas necessárias de configuração e gerenciamento. Os clientes que implantam instâncias do Amazon EC2 são responsáveis por [implantar instâncias do Amazon EC2 em vários locais](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) (como zonas de disponibilidade da AWS), [implementar a autorrecuperação](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) usando serviços como o Auto Scaling e usar as [práticas recomendadas de arquitetura de workload resiliente](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html) para aplicações instaladas nas instâncias. Para serviços gerenciados, como o Amazon S3 e o Amazon DynamoDB, a AWS opera a camada de infraestrutura, o sistema operacional e as plataformas, e os clientes acessam os endpoints para armazenar e recuperar dados. Você é responsável por gerenciar a resiliência dos dados incluindo estratégias de backup, versionamento e replicação.
Implantar a workload em várias zonas de disponibilidade em uma Região da AWS faz parte de uma estratégia de disponibilidade desenvolvida para proteger workloads isolando problemas a uma zona de disponibilidade, que usa a redundância de outras zonas de disponibilidade para continuar atendendo às solicitações. Uma arquitetura Multi-AZ também faz parte de uma estratégia de DR desenvolvida para que as workloads sejam mais isoladas e protegidas de problemas como queda de energia, raios, tornados, terremotos, dentre outros. As estratégias de DR também podem usar várias Regiões da AWS. Por exemplo, em uma configuração ativa/passiva, o serviço para a workload faz failover de sua região ativa para sua região de DR caso a região ativa não possa mais atender às solicitações.
![\[Tabela ilustrando o modelo de resiliência compartilhada.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/shared-model-resiliency.png)
É possível usar os serviços da AWS para cumprir seus objetivos de resiliência. Como cliente, você é responsável pelo gerenciamento dos seguintes aspectos de seu sistema para obter resiliência na nuvem. Para obter mais detalhes sobre cada serviço específico, consulte a [documentação da AWS](https://docs.aws.amazon.com/index.html).
**Redes, cotas e restrições**
+ As práticas recomendadas para essa área do modelo de responsabilidade compartilhada são descritas em detalhes em [Fundamentos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/foundations.html).
+ Planeje sua arquitetura com espaço adequado para escalar e entender as [cotas de serviço](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/manage-service-quotas-and-constraints.html) e as restrições dos serviços que você incluiu com base nos aumentos esperados de solicitações de carga, quando aplicável.
+ Projete sua [topologia de rede](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html) para ser altamente disponível, redundante e escalável.
**Gerenciamento de alterações e resiliência operacional**
+ O [gerenciamento de alterações](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/change-management.html) inclui como introduzir e gerenciar mudanças em seu ambiente. A [implementação de alterações](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/implement-change.html) requer a criação e a manutenção de runbooks atualizados e estratégias de implantação para sua aplicação e infraestrutura.
+ Uma estratégia resiliente para [monitorar os recursos da workload](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/monitor-workload-resources.html) considera todos os componentes, incluindo métricas técnicas e comerciais, notificações, automação e análise.
+ As workloads na nuvem devem [se adaptar às mudanças na escalação da demanda](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-adapt-to-changes-in-demand.html) em reação a deficiências ou flutuações no uso.
**Observabilidade e gerenciamento de falhas**
+ A observação de falhas por meio do monitoramento é necessária para automatizar a reparação para que suas workloads possam [suportar falhas de componentes](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html).
+ O [gerenciamento de falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/failure-management.html) requer [backup de dados](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/back-up-data.html), aplicação das práticas recomendadas para permitir que sua workload resista a falhas de componentes e [planejamento para recuperação de desastres](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html).
**Arquitetura da workload**
+ Sua [arquitetura de workload](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html) inclui como você projeta serviços em domínios de negócios, aplica SOA e design de sistema distribuído para evitar falhas e incorpora recursos como controle de utilização, novas tentativas, gerenciamento de filas, tempos limite e acionadores de emergência.
+ Confie em [soluções da AWS](https://aws.amazon.com/solutions/) comprovadas, na [Amazon Builders Library](https://aws.amazon.com/builders-library/) e em [padrões sem servidor](https://serverlessland.com/patterns) para se alinhar às práticas recomendadas e iniciar implementações.
+ Use melhorias contínuas para decompor o sistema em serviços distribuídos para escalar e inovar mais rapidamente. Use a orientação de [microsserviços da AWS](https://aws.amazon.com/microservices/) e as opções de serviços gerenciados para simplificar e acelerar sua capacidade de introduzir mudanças e inovar.
**Testes contínuos da infraestrutura crítica**
+ [Testar a confiabilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html) significa testar nos níveis funcional, de performance e caos, além de adotar análises de incidentes e práticas diárias para desenvolver experiência na resolução de problemas que não são bem compreendidos.
+ Para aplicações híbridas e completas na nuvem, saber como sua aplicação se comporta caso ocorra um problema ou os componentes fiquem inativos permite que você se recupere de interrupções de forma rápida e confiável.
+ Crie e documente experimentos repetíveis para entender como seu sistema se comporta quando as coisas não ocorrem da forma esperada. Esses testes provarão a eficácia de sua resiliência geral e fornecerão um loop de feedback dos seus procedimentos operacionais antes de enfrentar cenários de falha reais.
# Princípios de design
Na nuvem, há uma série de princípios que podem ajudar a aumentar a confiabilidade. Lembre-se disso ao discutirmos as práticas recomendadas:
+ **Recupere-se de falhas automaticamente:** ao monitorar os indicadores-chave de performance (KPIs) de uma workloads, você pode executar a automação quando um limite é violado. Esses KPIs devem ser uma medida do valor comercial, e não dos aspectos técnicos da operação do serviço. Isso permite a notificação automática e o rastreamento de falhas, além de processos de recuperação automatizados que solucionam ou reparam a falha. Com uma automação mais sofisticada, é possível antecipar e corrigir falhas antes que elas ocorram.
+ **Teste os procedimentos de recuperação:** em um ambiente on-premises, muitas vezes os testes são realizados para provar que a workload funciona em um cenário específico. Normalmente, o teste não é usado para validar estratégias de recuperação. Na nuvem, você pode testar o comportamento de falha da workload e validar os procedimentos de recuperação. É possível usar a automação para simular falhas diferentes ou para recriar cenários que levaram a falhas no passado. Essa abordagem expõe caminhos de falha que você pode testar e corrigir *antes* que um cenário de falha real ocorra, reduzindo assim o risco.
+ **Escale horizontalmente para aumentar a disponibilidade agregada da workload:** substitua um recurso grande por vários recursos pequenos para reduzir o impacto de uma única falha na workload geral. Distribua as solicitações por vários recursos menores para garantir que elas não compartilhem um ponto de falha comum.
+ **Pare de tentar adivinhar a capacidade:** uma causa comum de falha nas workloads on-premises é a saturação de recursos, quando as demandas impostas a uma workload excedem a respectiva capacidade (esse muitas vezes é o objetivo dos ataques de negação de serviço). Na nuvem, você pode monitorar a demanda e a utilização da workload e automatizar a adição ou a remoção de recursos para manter o nível ideal e atender à demanda, sem provisionamento excessivo ou subprovisionamento. Ainda há limites, mas algumas cotas podem ser controladas e outras podem ser gerenciadas (consulte [Gerenciar cotas e restrições de serviço](manage-service-quotas-and-constraints.md)).
+ **Gerencie alterações na automação:** as alterações em sua infraestrutura devem ser feitas por meio de automação. Entre aquelas que precisam ser gerenciadas estão as alterações na automação, que podem então ser acompanhadas e analisadas.
# Definições
Este whitepaper aborda a confiabilidade na nuvem, descrevendo as práticas recomendadas para estas quatro áreas:
+ Fundamentos
+ Arquitetura da workload
+ Gerenciamento de alterações
+ Gerenciamento de falhas
Para obter confiabilidade, você deve começar com os fundamentos: um ambiente em que cotas de serviço e topologia de rede acomodam a workload. A arquitetura da workload do sistema distribuído deve ser projetada para evitar e mitigar falhas. A workload deve processar as alterações na demanda ou nos requisitos e ser projetada para detectar falhas e se reparar automaticamente.
**Topics**
+ [
# Resiliência e os componentes da confiabilidade
](resiliency-and-the-components-of-reliability.md)
+ [
# Disponibilidade
](availability.md)
+ [
# Objetivos de recuperação de desastres (DR)
](disaster-recovery-dr-objectives.md)
# Resiliência e os componentes da confiabilidade
A confiabilidade de uma workload na nuvem depende de vários fatores, o principal deles é a *Resiliência*:
+ **Resiliência** é a capacidade de uma workload se recuperar de interrupções na infraestrutura ou nos serviços, adquirir dinamicamente recursos de computação para atender à demanda e mitigar interrupções, como configurações incorretas ou problemas transitórios de rede.
Os outros fatores que afetam a confiabilidade da workload são:
+ Excelência operacional, que inclui automação de alterações, uso de playbooks para responder a falhas e revisões de prontidão operacional (ORRs) para confirmar que as aplicações estão prontas para operações de produção.
+ Segurança, que inclui a prevenção de danos a dados ou infraestrutura de agentes mal-intencionados, o que pode afetar a disponibilidade. Por exemplo, criptografe backups para garantir que os dados estejam seguros.
+ Eficiência de performance, que inclui projetar para taxas máximas de solicitação e a minimização de latências para sua workload.
+ Otimização de custos, que inclui compensações, como se você deseja gastar mais em instâncias do EC2 para alcançar ajuste de escala automático ou confiar no ajuste de escala automático quando mais capacidade for necessária.
A resiliência é o foco principal deste whitepaper.
Os outros quatro fatores também são importantes e são cobertos por seus respectivos pilares do [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/). Muitas das práticas recomendadas aqui também resolvem esses aspectos da confiabilidade, mas o foco está na resiliência.
# Disponibilidade
A *Disponibilidade* (também conhecida como *disponibilidade de serviços*) é uma métrica comumente usada para medir quantitativamente a resiliência, bem como um objetivo de resiliência alvo.
+ A **disponibilidade** é a porcentagem de tempo durante a qual uma workload está disponível para uso.
*Disponível para uso* significa que ela executa a função combinada quando necessário.
Esse percentual é calculado em períodos como um mês, um ano ou os últimos três anos. Aplicando a interpretação mais estrita possível, a disponibilidade diminui sempre que a aplicação não está operando normalmente, incluindo interrupções agendadas e não agendadas. Definimos *disponibilidade* da seguinte forma:
![\[\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/availability-formula.png)
+ A disponibilidade é um percentual do tempo de atividade (como 99,9%) em um período (geralmente de um mês ou de um ano).
+ Uma forma comum de abreviar essas informações é mencionar apenas o “número de noves”. Por exemplo, “cinco noves” significa 99,999% disponível.
+ Alguns clientes preferem excluir o tempo de inatividade agendado do serviço (por exemplo, manutenção planejada) do *tempo total* na fórmula. No entanto, isso não é recomendado, uma vez que os usuários podem preferir usar o serviço durante essas horas.
Veja a seguir uma tabela das metas de design de disponibilidade de aplicação comuns e a máxima duração das interrupções que podem ocorrer em um ano sem que a meta deixe de ser atingida. A tabela contém exemplos dos tipos de aplicações comuns em cada nível de disponibilidade. Neste documento, vamos nos referir a esses valores.
| Disponibilidade | Indisponibilidade máxima (por ano) | Categorias de aplicações |
| --- | --- | --- |
| 99% | 3 dias e 15 horas | Tarefas de processamento em lote e de extração, transferência e carregamento de dados |
| 99,9% | 8 horas e 45 minutos | Ferramentas internas como gerenciamento de conhecimento e rastreamento de projetos |
| 99,95% | 4 horas e 22 minutos | Comércio online, ponto de vendas |
| 99,99% | 52 minutos | Workloads de entrega e broadcast de vídeo |
| 99,999% | 5 minutos | Workloads de transações em caixas eletrônicos, telecomunicações |
**Medição da disponibilidade com base nas solicitações.** Para seu serviço, talvez seja mais fácil contar as solicitações bem-sucedidas e com falha, em vez do "tempo disponível para uso". Nesse caso, o seguinte cálculo pode ser usado:
![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png)
Isso é medido com frequência para períodos de um minuto ou de cinco minutos. Então, um percentual de tempo ativo mensal (medição da disponibilidade baseada em tempo) pode ser calculado da média desses períodos. Se nenhuma solicitação for recebida em determinado período, ela será contada como 100% disponível nesse período.
**Cálculo de disponibilidade com dependências rígidas.** Muitos sistemas têm dependências rígidas de outros sistemas, onde uma interrupção de um sistema dependente leva diretamente a uma interrupção do sistema que o invocou. Isso é o oposto de uma dependência flexível, em que uma falha do sistema dependente é compensada na aplicação. Quando ocorrem essas dependências rígidas, a disponibilidade do sistema invocador é o produto das disponibilidades dos sistemas dependentes. Por exemplo, se você tiver um sistema projetado para uma disponibilidade de 99,99% que tenha uma dependência rígida de outros dois sistemas independentes, cada um projetado para uma disponibilidade de 99,99%, a workload teoricamente poderá atingir uma disponibilidade de 99,97%:
Availinvok × Avail*dep1* × Avail*dep2* = Availworkload
99,99% × 99,99% × 99,99% = 99,97%
Portanto, é importante entender suas dependências e as respectivas metas de design de disponibilidade ao calcular as suas próprias.
**Cálculo de disponibilidade com componentes redundantes.** Quando um sistema envolve o uso de componentes independentes e redundantes (por exemplo, recursos redundantes em diferentes zonas de disponibilidade), a disponibilidade teórica é calculada como 100% menos o produto das taxas de falha dos componentes. Por exemplo, se um sistema usar dois componentes independentes, cada um com uma disponibilidade de 99,9%, a disponibilidade efetiva dessa dependência será 99,9999%:
![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/image2.png)
Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency))
99,9999% = 100% − (0,1%×0,1%)
*Cálculo com atalho*: se as disponibilidades de todos os componentes em seu cálculo consistirem apenas no dígito nove, você poderá somar a contagem do número de nove dígitos para obter a resposta. No exemplo acima, dois componentes independentes e redundantes com disponibilidade de três noves resultam em seis noves.
**Cálculo da disponibilidade da dependência.** Algumas dependências fornecem orientações sobre a disponibilidade delas, incluindo metas de design da disponibilidade para muitos serviços da AWS. Porém, em casos em que isso não está disponível (por exemplo, um componente em que o fabricante não publica informações de disponibilidade), uma maneira de estimar é determinar o **tempo médio entre falhas (MTBF)** e o **tempo médio para recuperação (MTTR)**. É possível estabelecer a estimativa de disponibilidade da seguinte maneira:
![\[\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png)
Por exemplo, se o MTBF for 150 dias e o MTTR for 1 hora, a estimativa de disponibilidade será 99,97%.
Para obter detalhes adicionais, consulte [Disponibilidade e além: como entender e melhorar a resiliência de sistemas distribuídos na AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html) para obter ajuda para calcular sua disponibilidade.
**Custos para a disponibilidade.** Desenvolver aplicações para níveis mais altos de disponibilidade costuma resultar em mais custos. Assim, é importante identificar as verdadeiras necessidades de disponibilidade antes de iniciar o design da aplicação. Altos níveis de disponibilidade impõem exigências maiores para teste e validação sob cenários de falha exaustivos. Eles exigem automação para recuperação de todos os tipos de falhas e exigem que todos os aspectos das operações do sistema sejam criados e testados de modo similar conforme os mesmos padrões. Por exemplo, as ações de adicionar ou remover capacidade, implantar ou reverter software atualizado ou alterações de configuração ou migrar dados do sistema devem ser feitas conforme a meta de disponibilidade desejada. Contribuindo com os custos de desenvolvimento de software, em níveis muito altos de disponibilidade, a inovação é prejudicada devido à necessidade de avançar mais lentamente na implantação dos sistemas. Assim, a orientação é ter cautela ao aplicar os padrões e considerar o objetivo de disponibilidade adequado para todo o ciclo de vida de operação do sistema.
A seleção de dependências também contribui para o aumento dos custos em sistemas que operam com metas de design de disponibilidade maiores. Com esses objetivos maiores, o conjunto de software ou serviços que podem ser escolhidos como dependências diminui com base em quais receberam os investimentos elevados descritos anteriormente. Conforme a meta de design de disponibilidade aumenta, é comum encontrar menos serviços multiuso (como um banco de dados relacional) e mais serviços direcionados a uma finalidade específica. Isso acontece porque estes são mais fáceis de avaliar, testar e automatizar e têm menos potencial de interações inesperadas com funcionalidade incluída, mas não utilizada.
# Objetivos de recuperação de desastres (DR)
Além dos objetivos de disponibilidade, a estratégia de resiliência também deve incluir objetivos de recuperação de desastres (DR) baseados em estratégias para recuperar a workload em caso de um desastre. A recuperação de desastres se concentra em objetivos de recuperação de uma única vez em resposta a desastres naturais, a falhas técnicas em grande escala ou a ameaças humanas, como ataques ou erros. Isso difere da disponibilidade que mede a resiliência por um período em resposta a falhas de componentes, a picos de carga ou a erros de software.
**Objetivo de tempo de recuperação (RTO)** definido pela organização. O RTO é o atraso máximo aceitável entre a interrupção e a restauração do serviço. Ele determina o que é considerado uma janela de tempo aceitável quando o serviço não está disponível.
**Objetivo de ponto de recuperação (RPO)** definido pela organização. O RPO é o período máximo de tempo aceitável desde o último ponto de recuperação de dados. Isso determina o que é considerado uma perda aceitável de dados entre o último ponto de recuperação e a interrupção do serviço.
![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/business-continuity.png)
*A relação do objetivo de ponto de recuperação (RPO), objetivo do tempo de recuperação (RTO) e o evento de desastre.*
O RTO é semelhante ao MTTR, pois ambos medem o tempo entre o início de uma interrupção e a recuperação da workload. No entanto, o MTTR é um valor médio assumido em vários eventos que afetam a disponibilidade ao longo de um período, enquanto RTO é um destino, ou valor máximo permitido, para um *único* evento que afeta a disponibilidade.
# Como entender as necessidades de disponibilidade
É comum pensar inicialmente na disponibilidade de uma aplicação como um único objetivo para a aplicação como um todo. Porém, com uma inspeção mais detalhada, é comum descobrirmos que determinados aspectos de uma aplicação ou serviço têm requisitos de disponibilidade diferentes. Por exemplo, alguns sistemas podem priorizar a capacidade de receber e armazenar novos dados antes de recuperar dados existentes. Outros sistemas priorizam operações em tempo real sobre operações que mudam a configuração ou o ambiente de um sistema. Os serviços podem ter requisitos de disponibilidade muito altos durante determinados horários do dia, mas podem tolerar períodos muito mais longos de interrupção fora desses horários. Estas são algumas das maneiras como você pode dividir uma única aplicação nas partes que a compõem e avaliar os requisitos de disponibilidade de cada uma. O benefício de fazer isso é concentrar os esforços (e as despesas) de disponibilidade conforme as necessidades específicas, em vez de projetar todo o sistema conforme o requisito mais rígido.
| Recomendação |
| --- |
| Avalie de modo crítico os aspectos exclusivos de suas aplicações e, quando adequado, diferencie as metas de design de disponibilidade e de recuperação de desastres para refletirem as necessidades de sua empresa. |
Na AWS, normalmente dividimos os serviços em "plano de dados" e "ambiente de gerenciamento". 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. Por exemplo, instâncias do Amazon EC2, bancos de dados do Amazon RDS e operações de leitura/gravação de tabela do Amazon DynamoDB são operações no plano de dados. Em contraste, iniciar novas instâncias do EC2 ou bancos de dados do RDS ou adicionar ou alterar metadados de tabela no DynamoDB são consideradas operações no ambiente de gerenciamento. Embora altos níveis de disponibilidade sejam importantes para todas essas capacidades, os planos de dados costumam ter metas de design de disponibilidade maiores que os ambientes de gerenciamento. Portanto, as workloads com requisitos de alta disponibilidade devem evitar a dependência de tempo de execução nas operações do ambiente de gerenciamento.
Muitos dos clientes da AWS adotam uma abordagem similar para avaliar de modo crítico suas aplicações e identificar subcomponentes com diferentes necessidades de disponibilidade. As metas de design de disponibilidade são personalizadas para os diferentes aspectos, e os esforços de trabalho adequados são empregados para projetar o sistema. A AWS possui experiência significativa de aplicações de engenharia com uma série de metas de design de disponibilidade, incluindo serviços com 99,999% ou mais de disponibilidade. AWS Os arquitetos de soluções (SAs) podem ajudar você a projetar adequadamente conforme suas metas de disponibilidade. Envolver a AWS no início do processo de design melhora nossa capacidade de ajudar você a atingir suas metas de disponibilidade. O planejamento da disponibilidade não é feito apenas antes do início de sua workload. Isso também é feito de modo contínuo para refinar seu design conforme você ganha experiência operacional, aprende com eventos do mundo real e tolera falhas de diferentes tipos. Assim você pode aplicar o esforço de trabalho adequado para melhorar sua implementação.
As necessidades de disponibilidade necessárias para uma workload devem estar alinhadas à necessidade e à criticidade da empresa. Ao definir primeiro a estrutura de criticidade empresarial com RTO, RPO e disponibilidade específicos, é possível avaliar cada workload. Essa abordagem exige que as pessoas envolvidas na implementação da workload tenham conhecimento da estrutura e do impacto que sua workload tem sobre as necessidades empresariais.