

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

Data de publicação: **6 de novembro de 2024** ([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 seguras, confiáveis, eficientes, econômicas e sustentáveis na Nuvem AWS. Ele fornece uma maneira de avaliar de forma consistente suas arquiteturas em relação às práticas recomendadas e identificar áreas para melhorias. O processo para analisar 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 contam com 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 continuar evoluindo 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 obter mais informações, consulte a [página inicial do AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/?ref=wellarchitected-wp). 

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

 Para ajudar você a aplicar as práticas recomendadas, criamos os [Laboratórios do AWS Well-Architected](https://www.wellarchitectedlabs.com/?ref=wellarchitected-wp), os quais fornecem um repositório de código e documentação para ajudar a simplificar a implementação dessas práticas. Também nos juntamos a parceiros selecionados da Rede de Parceiros da AWS (APN) 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** 


|  **Nome**  |  **Descrição**  | 
| --- | --- | 
|  Excelência operacional  |  A capacidade de apoiar o desenvolvimento e executar workloads 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 forma que possa melhorar sua postura de segurança. | 
|  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.  | 
|  Eficiência de performance  |  A capacidade de usar recursos de computação de forma eficiente para atender aos requisitos do sistema e manter essa eficiência à medida que a demanda muda e as tecnologias evoluem.  | 
|  Otimização de custo  |  A capacidade de executar sistemas para agregar valor de negócio pelo 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: 
+  Um **componente** é o código, configuração e 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 **workload** é usado para identificar um conjunto de componentes que entrega o valor empresarial. Uma workload é normalmente o nível de detalhes sobre o qual os líderes de negócios e tecnologia se comunicam. 
+  Pensamos na **arquitetura** como sendo a forma como os componentes trabalham juntos em uma workload. Como os componentes se comunicam e interagem é, com frequência, o foco dos diagramas de arquitetura. 
+  Os **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 workloads 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 demorar várias semanas ou vários meses. Ele poderia ser dividido em vários lançamentos, histórias e tarefas. 
  + **Médio:** o trabalho pode demorar vários dias ou várias semanas. Ele poderia ser dividido em vários lançamentos e tarefas.
  + **Baixo:** o trabalho pode demorar várias horas ou vários dias. Ele 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 comerciais podem determinar 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 se envolvem em trocas com os 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. Muitas vezes, essas equipes usam o [TOGAF](https://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework) 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, adotamos *práticas* (processos, padrões, normas aceitas e formas de fazer as coisas) que têm como foco 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. Em seguida, implementamos *mecanismos* que realizam verificações automatizadas para descobrir 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 é apoiada 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 é *determinada pelo cliente* 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. 

 Para a 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 líderes que podem analisar os projetos e ajudá-las a entender quais são as práticas recomendadas da AWS. A comunidade de engenheiros líderes 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 práticas recomendadas 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 líderes, para defini-las. À medida que os engenheiros líderes 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 líderes 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 de 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 tentar adivinhar suas necessidades de capacidade:** se você tomar uma decisão ruim relacionada à capacidade ao implantar uma workload, 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 uma quantidade de capacidade qualquer de acordo com suas necessidades do momento e aumentar e diminuir a escala automaticamente. 
+  **Teste seus 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 desativar 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 experimentação arquitetural em mente:** a automação permite criar e replicar as workloads por custos baixos e evitar as despesas do trabalho manual. Você pode rastrear as alterações em sua automação, auditar o impacto e reverter para os parâmetros anteriores quando necessário. 
+  **Considere arquiteturas evolucionárias:** 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 workload. 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. 
+  **Faça aprimoramentos com os game days:** 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 é possível aplicar melhorias e pode ajudar a desenvolver experiência organizacional ao lidar com eventos. 