

# AWS Well-Architected Framework
<a name="welcome"></a>

Data de publicação: **3 de outubro de 2023** ([Revisões do documento](document-revisions.md))

O AWS Well-Architected Framework ajuda a entender os prós e os contras das decisões que você toma ao criar sistemas na AWS. Ao usar o Framework, você terá acesso a práticas recomendadas de arquitetura para projetar e operar sistemas confiáveis, seguros, eficientes, econômicos e sustentáveis na nuvem.

## Introdução
<a name="introduction"></a>

 O AWS Well-Architected Framework ajuda a entender os prós e os contras das decisões que você toma ao criar sistemas na AWS. O uso do Framework ajuda você a aprender as práticas recomendadas de arquitetura para projetar e operar workloads confiáveis, seguras, eficientes, econômicas e sustentáveis na Nuvem AWS. Ele fornece uma maneira de você avaliar consistentemente suas arquiteturas em relação às práticas recomendadas e identificar áreas de melhoria. O processo para revisar uma arquitetura é uma conversa construtiva sobre decisões de arquitetura e não é um mecanismo de auditoria. Acreditamos que ter sistemas bem projetados aumenta significativamente a probabilidade de sucesso dos negócios. 

 Os arquitetos de soluções da AWS têm vários anos de experiência em arquitetura de soluções em uma ampla variedade de segmentos de negócios verticais e casos de uso. Ajudamos a projetar e analisar as arquiteturas de milhares de clientes na AWS. Por meio dessa experiência, identificamos as práticas recomendadas e principais estratégias para a arquitetura de sistemas na nuvem. 

 O AWS Well-Architected Framework documenta um conjunto de perguntas fundamentais que ajudam a compreender se uma arquitetura específica se alinha bem às práticas recomendadas da nuvem. Ele fornece uma abordagem consistente para avaliar os sistemas em relação às qualidades que você espera dos sistemas modernos baseados em nuvem e a correção necessária para alcançar essas qualidades. À medida que a AWS evoluir, e continuarmos a aprender mais com o trabalho com nossos clientes, aprimoraremos ainda mais a definição do Well-Architected. 

 Este Framework é destinado a pessoas que ocupam cargos de tecnologia, como diretores de tecnologia (CTOs), arquitetos, desenvolvedores e membros da equipe de operações. Ele descreve as práticas recomendadas e as estratégias da AWS a serem usadas ao projetar e operar uma workload na nuvem, além de fornecer links para detalhes de implementação e padrões de arquitetura adicionais. Para mais informações, leia a [Página inicial do AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/?ref=wellarchitected-wp). 

 A AWS também fornece um serviço para analisar suas workloads gratuitamente. O [Ferramenta AWS Well-Architected](https://aws.amazon.com/well-architected-tool/?ref=wellarchitected-wp) (Ferramenta AWS WA) é um serviço na nuvem que fornece um processo consistente para analisar e medir a arquitetura usando o AWS Well-Architected Framework. A AWS WA Tool fornece recomendações para tornar suas workloads mais confiáveis, seguras, eficientes e econômicas. 

 Para ajudá-lo a aplicar as melhores práticas, criamos os [AWS Well-Architected Labs](https://www.wellarchitectedlabs.com/?ref=wellarchitected-wp), que fornecem um repositório de código e documentação para oferecer experiência prática na implementação das melhores práticas. Também nos associamos a parceiros selecionados da Rede de Parceiros da AWS (APN), que são membros do [Programa de parceiros do AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/partners/?ref=wellarchitected-wp). Esses parceiros da AWS têm profundo conhecimento sobre a AWS e podem ajudar você a analisar e melhorar suas workloads. 

# Definições
<a name="definitions"></a>

 Todos os dias, os especialistas da AWS ajudam os clientes a projetar sistemas para aproveitar as práticas recomendadas na nuvem. Trabalhamos com você para oferecer vantagens e desvantagens arquitetônicas à medida que seus projetos evoluem. Conforme você implanta esses sistemas em ambientes dinâmicos, aprendemos como esses sistemas se desempenham e as consequências dessas vantagens e desvantagens. 

 Com base no que aprendemos, criamos o AWS Well-Architected Framework, que fornece um conjunto consistente de práticas recomendadas para os clientes e parceiros avaliarem arquiteturas e um conjunto de perguntas que você pode usar para avaliar o alinhamento de uma arquitetura com as práticas recomendadas da AWS. 

 O AWS Well-Architected Framework é baseado em seis pilares: excelência operacional, segurança, confiabilidade, eficiência de performance, otimização de custos e sustentabilidade. 

 **Tabela 1. Os pilares do AWS Well-Architected Framework** 


|  **Name (Nome)**  |  **Descrição**  | 
| --- | --- | 
|  Excelência operacional  |  A capacidade de apoiar o desenvolvimento e executar cargas de trabalho com eficácia, obter insights sobre as operações e melhorar continuamente processos e procedimentos de suporte para oferecer valor empresarial.  | 
|  Segurança  | O pilar de segurança descreve como aproveitar as tecnologias de nuvem para proteger dados, sistemas e ativos de uma maneira que possa melhorar sua postura de segurança. | 
|  Confiabilidade  |  O pilar Confiabilidade abrange a capacidade de uma carga de trabalho de executar a função pretendida correta e consistentemente quando esperado. Isso inclui a capacidade de operar e testar a carga de trabalho 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.  | 
|  Eficiência de performance  |  A capacidade de usar recursos de computação com eficiência para atender aos requisitos do sistema e manter essa eficiência à medida que a demanda muda e as tecnologias evoluem.  | 
|  Otimização dos custos  |  A capacidade de executar sistemas para entregar o valor empresarial ao menor preço.  | 
|  Sustentabilidade  |  A possibilidade de melhorar continuamente os impactos sobre a sustentabilidade com a redução do consumo de energia e o aumento da eficiência de todos os componentes de uma workload por meio da maximização dos benefícios dos recursos provisionados e da minimização do total de recursos necessários.  | 

 No AWS Well-Architected Framework, usamos estes termos: 
+  A **componente** é o código, a configuração e os recursos da AWS que, juntos, atendem a um requisito. Um componente geralmente é a unidade de propriedade técnica e é dissociada de outros componentes. 
+  O termo **carga de trabalho** é usado para identificar um conjunto de componentes que entrega o valor empresarial. Uma carga de trabalho é normalmente o nível de detalhes sobre o qual os líderes de negócios e tecnologia se comunicam. 
+  Pensamos na **arquitetura** como sendo os componentes que trabalham juntos em uma carga de trabalho. Como os componentes se comunicam e interagem é, com frequência, o foco dos diagramas de arquitetura. 
+  **Marcos** assinalam as principais alterações em sua arquitetura, à medida que evoluem ao longo do ciclo de vida do produto (design, implementação teste, ativação e produção). 
+  Dentro de uma organização o **portfólio de tecnologia** é a coleção de cargas de trabalho necessárias para o negócio operar. 
+ O **nível de esforço** refere-se à categorização da quantidade de tempo, esforço e complexidade que uma tarefa exige para implementação. Cada organização precisa considerar o tamanho e a especialização da equipe, além da complexidade da workload, a fim de ter contexto adicional para categorizar adequadamente o respectivo nível de esforço.
  + **Alto:** O trabalho pode levar várias semanas ou vários meses. Isso poderia ser dividido em vários lançamentos, histórias e tarefas. 
  + **Médio:** O trabalho pode levar vários dias ou várias semanas. Isso poderia ser dividido em vários lançamentos e tarefas.
  + **Baixo:** O trabalho pode levar várias horas ou vários dias. Isso poderia ser dividido em várias tarefas.

 Ao arquitetar workloads, você obtém vantagens e desvantagens entre os pilares com base no contexto da sua empresa. Essas decisões de negócios podem definir suas prioridades de engenharia. Você pode otimizar para melhorar o impacto sobre a sustentabilidade e reduzir os custos à custa da confiabilidade em ambientes de desenvolvimento ou, no caso de soluções essenciais à missão, otimizar a confiabilidade e aumentar os custos e o impacto sobre a sustentabilidade. Em soluções de comércio eletrônico, a performance pode afetar a receita e a propensão do cliente a comprar. Segurança e excelência operacional geralmente não têm vantagens e desvantagens em relação aos outros pilares. 

# Sobre arquitetura
<a name="on-architecture"></a>

 Em ambientes on-premises, os clientes geralmente têm uma equipe central de arquitetura de tecnologia que atua como uma sobreposição para outras equipes de produtos ou atributos para verificar se estão seguindo as práticas recomendadas. As equipes de arquitetura de tecnologia tipicamente incluem um conjunto de funções, como arquiteto técnico (infraestrutura), arquiteto de soluções (software), arquiteto de dados, arquiteto de redes e arquiteto de segurança. Geralmente, essas equipem usam o [TOGAF](https://pubs.opengroup.org/architecture/togaf9-doc/arch/) ou o [Zachman Framework](https://zachman-feac.com/zachman/about-the-zachman-framework) como parte de um recurso de arquitetura corporativa. 

 Na AWS, preferimos distribuir os recursos entre equipes, em vez de termos uma equipe centralizada com esses recursos. Existem riscos na escolha de distribuir autoridade para tomada de decisões, por exemplo, verificar se as equipes atendem aos padrões internos. Atenuamos esses riscos de duas formas. Primeiro, nós temos *práticas* (processos, padrões, normas aceitas e formas de fazer as coisas) que se concentram em permitir que cada equipe tenha essa capacidade, e utilizamos especialistas que verificam se as equipes elevam o nível dos padrões que elas precisam cumprir. Segundo, implementamos *mecanismos* que realizam verificações automatizadas para verificar se os padrões estão sendo atendidos.

****  
 “Boas intenções nunca funcionam, você precisa de bons mecanismos para fazer qualquer coisa acontecer” — Jeff Bezos. 

Isso significa substituir os melhores esforços humanos por mecanismos (muitas vezes automatizados) que examinam a conformidade com base em regras ou processos. Essa abordagem distribuída é embasada pelos [princípios de liderança da Amazon](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp)e estabelece uma cultura em todas as funções que *retornam* do cliente. Trabalhar de trás para a frente é uma parte fundamental do nosso processo de inovação. Começamos com o cliente e o que ele quer, e deixamos isso definir e orientar nossos esforços. As equipes dedicadas ao cliente criam produtos em resposta a uma necessidade do cliente. 

 Na arquitetura, isso significa que esperamos que todas as equipes tenham a capacidade de criar arquiteturas e seguir as práticas recomendadas. Para ajudar as novas equipes a obter essas capacidades ou as equipes existentes a elevar seus padrões, ativamos o acesso a uma comunidade virtual de engenheiros-chefes que podem analisar os projetos e ajudá-las a entender quais são as práticas recomendadas da AWS. A comunidade de engenheiros-chefe trabalha para que as práticas recomendadas sejam visíveis e acessíveis. Uma forma de fazer isso, por exemplo, é por meio de palestras na hora do almoço, focadas na aplicação das melhores práticas a exemplos reais. Essas conversas são gravadas e podem ser usadas como parte dos materiais de integração para novos membros da equipe. 

 As práticas recomendadas da AWS surgem de nossa experiência na execução de milhares de sistemas em escala da internet. Preferimos usar dados para definir as práticas recomendadas, mas também usamos especialistas, como engenheiros-chefes, para defini-las. À medida que os engenheiros-chefes veem surgir novas práticas recomendadas, eles trabalham como uma comunidade para verificar se elas estão sendo seguidas pelas equipes. Com o tempo, essas práticas recomendadas são formalizadas em nossos processos internos de análise, bem como em mecanismos que reforçam a conformidade. O Well-Architected Framework é a implementação voltada para o cliente do nosso processo de análise interna, no qual codificamos nosso pensamento de engenharia principal nas funções de campo, como a arquitetura de soluções e equipes de engenharia internas. O Well-Architected Framework é um mecanismo escalável que permite que você aproveite esses aprendizados. 

 Seguindo a abordagem de uma comunidade de engenheiros-chefes com propriedade distribuída de arquitetura, acreditamos que uma arquitetura corporativa do Well-Architected pode emergir, impulsionada pela necessidade do cliente. Líderes de tecnologia (como CTOs ou gerentes de desenvolvimento), realizando análises do Well-Architected em todas as workloads, permitirão uma melhor compreensão dos riscos no portfólio de tecnologia. Usando essa abordagem, você pode identificar temas entre as equipes que sua organização poderia abordar por mecanismos, treinamentos ou palestras na hora do almoço, em que seus engenheiros principais possam compartilhar seus pensamentos sobre áreas específicas com várias equipes. 

# Princípios gerais do projeto
<a name="general-design-principles"></a>

 O Well-Architected Framework identifica um conjunto de princípios gerais do projeto para facilitar um bom projeto na nuvem: 
+  **Pare de adivinhar suas demandas de capacidade**: se você tomar uma decisão ruim relacionada à capacidade ao implantar uma carga de trabalho, poderá acabar com recursos ociosos caros ou lidando com as implicações da performance da capacidade limitada. Com a computação em nuvem, esses problemas terminaram. Você pode usar a quantidade de capacidade e aumentar e diminuir a escala automaticamente. 
+  **Teste sistemas em escala de produção**: na nuvem, você pode criar um ambiente de teste em escala de produção sob demanda, concluir seus testes e descomissionar os recursos. Como você paga somente pelo ambiente de teste quando está em execução, é possível simular seu ambiente ativo por uma fração do custo dos testes on-premises. 
+  **Automatize com a experimentação da arquitetura em mente**: a automação permite criar e replicar as workloads por custos baixos e evitar as despesas do trabalho manual. Você pode acompanhar as alterações em sua automação, auditar o impacto e reverter para os parâmetros anteriores quando necessário. 
+  **Pense em arquiteturas evolutivas**: em um ambiente tradicional, as decisões de arquitetura são frequentemente implementadas como eventos estáticos e únicos, com algumas versões principais de um sistema durante sua vida útil. À medida que uma empresa e seu contexto continuam a evoluir, essas decisões iniciais podem prejudicar a capacidade do sistema de fornecer requisitos de negócios variáveis. Na nuvem, a capacidade de automatizar e testar sob demanda reduz o risco de impacto das alterações no projeto. Isso permite que os sistemas evoluam com o tempo, para que as empresas possam tirar proveito das inovações como prática padrão. 
+  **Impulsione arquiteturas usando dados**: na nuvem, você pode coletar dados sobre como suas escolhas de arquitetura afetam o comportamento da carga de trabalho. Isso permite que você tome decisões baseadas em fatos sobre como melhorar sua workload. Sua infraestrutura de nuvem é código, portanto, você pode usar esses dados para informar suas escolhas e melhorias na arquitetura ao longo do tempo. 
+  **Aprimore por meio dos dias de jogo**: teste a performance e os processos de sua arquitetura, agendando regularmente dias de jogo para simular eventos em produção. Isso ajudará a compreender onde as melhorias podem ser feitas e pode ajudar a desenvolver experiência organizacional ao lidar com eventos. 