

# Apêndice: Perguntas e práticas recomendadas
<a name="appendix"></a>

Este apêndice resume todas as perguntas e práticas recomendadas do AWS Well-Architected Framework.

**Topics**
+ [Excelência operacional](a-operational-excellence.md)
+ [Segurança](a-security.md)
+ [Confiabilidade](a-reliability.md)
+ [Eficiência de performance](a-performance-efficiency.md)
+ [Otimização de custos](a-cost-optimization.md)
+ [Sustentabilidade](a-sustainability.md)

# Excelência operacional
<a name="a-operational-excellence"></a>

O pilar Excelência operacional inclui a capacidade de oferecer conformidade com o desenvolvimento e de executar workloads com eficácia, obter insights sobre as operações e melhorar continuamente processos e procedimentos de suporte para oferecer valor empresarial. Você pode encontrar orientações prescritivas sobre implementação no [whitepaper sobre o pilar de excelência operacional](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html). 

**Topics**
+ [Organização](a-organization.md)
+ [Preparar](a-prepare.md)
+ [Operar](a-operate.md)
+ [Evoluir](a-evolve.md)

# Organização
<a name="a-organization"></a>

**Topics**
+ [OPERAÇÕES 1. Como determinar quais são suas prioridades?](ops-01.md)
+ [OPERAÇÕES 2. Como estruturar sua organização para dar suporte aos resultados comerciais?](ops-02.md)
+ [OPERAÇÕES 3. Como sua cultura organizacional oferece suporte aos resultados comerciais?](ops-03.md)

# OPERAÇÕES 1. Como determinar quais são suas prioridades?
<a name="ops-01"></a>

 Todos devem entender seu papel no sucesso dos negócios. Tenha objetivos compartilhados para definir as prioridades dos recursos. Isso maximizará os benefícios de seus esforços. 

**Topics**
+ [OPS01-BP01 Avaliar as necessidades dos clientes externos](ops_priorities_ext_cust_needs.md)
+ [OPS01-BP02 Avalie as necessidades dos clientes internos](ops_priorities_int_cust_needs.md)
+ [OPS01-BP03 Avaliar os requisitos de governança](ops_priorities_governance_reqs.md)
+ [OPS01-BP04 Avaliar os requisitos de conformidade](ops_priorities_compliance_reqs.md)
+ [OPS01-BP05 Avaliar o cenário de ameaças](ops_priorities_eval_threat_landscape.md)
+ [OPS01-BP06 Avalie as compensações](ops_priorities_eval_tradeoffs.md)
+ [OPS01-BP07 Gerenciar os benefícios e os riscos](ops_priorities_manage_risk_benefit.md)

# OPS01-BP01 Avaliar as necessidades dos clientes externos
<a name="ops_priorities_ext_cust_needs"></a>

 Envolva as principais partes interessadas, incluindo equipes corporativas, de desenvolvimento e operacionais, a fim de determinar onde concentrar os esforços nas necessidades de clientes externos. Isso garantirá que você tenha um entendimento completo do suporte às operações necessário para obter os resultados desejados nos negócios. 

 **Antipadrões comuns:** 
+  Você decidiu não ter suporte ao cliente fora do horário comercial principal, mas não analisou dados históricos de solicitação de suporte. Você não sabe se isso afetará seus clientes. 
+  Você está desenvolvendo um novo recurso, mas não envolveu seus clientes para descobrir se ele é desejado, em qual formato é desejado e sem experimentação para validar a necessidade e o método de entrega. 

 **Benefícios do estabelecimento desta prática recomendada:** Os clientes cujas necessidades estão atendidas têm muito mais probabilidade de permanecerem como clientes. Avaliar e compreender as necessidades de clientes externos informará como você priorizará seus esforços para entregar valor empresarial. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Compreender as necessidades empresariais: o sucesso nos negócios é possibilitado pelos objetivos e pelo entendimento compartilhados entre as partes interessadas, incluindo equipes corporativas, de desenvolvimento e de operações. 
  +  Analisar os objetivos, as necessidades e as prioridades empresariais dos clientes externos: envolva as principais partes interessadas, incluindo as equipes corporativas, de desenvolvimento e de operações, para discutir as metas, as necessidades e as prioridades dos clientes externos. Isso garantirá que você tenha um entendimento completo do suporte às operações que é necessário para obter resultados nos negócios. 
  +  Estabelecer uma compreensão compartilhada: estabeleça uma compreensão compartilhada das funções corporativas sobre a workload, as funções de cada uma das equipes na operação da workload e de como esses fatores oferecem apoiam seus objetivos empresariais compartilhados entre os clientes internos e externos. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Well-Architected Framework Concepts – Feedback loop (Conceitos do AWS Well-Architected Framework: loop de feedback)](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) 

# OPS01-BP02 Avalie as necessidades dos clientes internos
<a name="ops_priorities_int_cust_needs"></a>

 Envolva as principais partes interessadas, incluindo equipes corporativas, de desenvolvimento e operacionais, ao determinar onde concentrar os esforços nas necessidades de clientes internos. Isso garantirá que você tenha um entendimento completo do suporte às operações necessário para obter resultados nos negócios. 

 Use suas prioridades estabelecidas para concentrar seus esforços de melhoria onde eles terão maior impacto (por exemplo, desenvolvendo habilidades de equipe, melhorando a performance da carga de trabalho, reduzindo custos, automatizando runbooks ou aprimorando o monitoramento). Atualize suas prioridades conforme as necessidades mudam. 

 **Antipadrões comuns:** 
+  Você decidiu alterar as alocações de endereços IP para suas equipes de produtos, sem consultá-las, para facilitar o gerenciamento da sua rede. Você não sabe o impacto que isso terá em suas equipes de produtos. 
+  Você está implementando uma nova ferramenta de desenvolvimento, mas não envolveu seus clientes internos para descobrir se ela é necessária ou se é compatível com as práticas que eles realizam. 
+  Você está implementando um novo sistema de monitoramento, mas não entrou em contato com seus clientes internos para descobrir se eles têm necessidades de monitoramento ou relatórios que devam ser consideradas. 

 **Benefícios do estabelecimento desta prática recomendada:** Avaliar e compreender as necessidades de clientes internos informará como você priorizará seus esforços para entregar valor empresarial. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Compreenda as necessidades empresariais: o sucesso nos negócios é possibilitado pelos objetivos e pelo entendimento compartilhados entre as partes interessadas, incluindo equipes corporativas, de desenvolvimento e de operações. 
  +  Analise os objetivos, as necessidades e as prioridades empresariais dos clientes internos: envolva as principais partes interessadas, incluindo as equipes corporativas, de desenvolvimento e de operações, para discutir as metas, as necessidades e as prioridades dos clientes internos. Isso garantirá que você tenha um entendimento completo do suporte às operações que é necessário para obter resultados nos negócios. 
  +  Estabeleça uma compreensão compartilhada: estabeleça um entendimento compartilhado das funções corporativas sobre a workload, as funções de cada uma das equipes na operação da workload e de como esses fatores apoiam seus objetivos empresariais compartilhados entre os clientes internos e externos. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Well-Architected Framework Concepts – Feedback loop (Conceitos do AWS Well-Architected Framework: loop de feedback)](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) 

# OPS01-BP03 Avaliar os requisitos de governança
<a name="ops_priorities_governance_reqs"></a>

 Governança refere-se a um conjunto de políticas, regras ou frameworks que uma empresa usa para atingir metas de negócios. Os requisitos de governança são gerados dentro da organização. Eles podem afetar os tipos de tecnologia que você escolhe ou influenciar a maneira como você opera sua workload. Incorpore requisitos de governança organizacional em sua workload. Conformidade é a capacidade de demonstrar que você implementou os requisitos de governança. 

 **Resultado desejado:** 
+  Os requisitos de governança são incorporados ao design arquitetural e à operação da workload. 
+  Você pode fornecer prova de que seguiu os requisitos de governança. 
+  Os requisitos de governança são revistos e atualizados regularmente. 

 **Antipadrões comuns:** 
+ Sua organização exige que a conta raiz tenha autenticação multifator. Você não implementa esse requisito e a conta raiz é comprometida.
+ Durante o design da workload, você escolhe um tipo de instância que não é aprovada pelo departamento de TI. Você não consegue iniciar a workload e precisa começar a reprojetá-la.
+ É obrigatório que você tenha um plano de recuperação de desastres. Você não cria um, e a workload sofre uma interrupção prolongada.
+  Sua equipe quer usar novas instâncias, mas seus requisitos de governança não foram atualizados para permiti-las. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  A aderência aos requisitos de governança alinha sua workload às políticas da organização como um todo. 
+  Os requisitos de governança refletem os padrões e as práticas recomendas do setor para sua organização. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

Identifique o requisito de governança trabalhando com as partes interessadas e as organizações de governança. Inclua os requisitos de governança em sua workload. Prepare-se para demonstrar prova de que você seguiu os requisitos de governança.

 **Exemplo de clientes** 

 Na Loja UmaEmpresa, a equipe de operações em nuvem trabalha com as partes interessadas dentro da organização para desenvolver requisitos de governança. Por exemplo, eles proíbem acesso SSH a instâncias do Amazon EC2. Caso as equipes precisem de acesso ao sistema, elas devem usar o AWS Systems Manager Session Manager. A equipe de operações em nuvem atualiza regularmente os requisitos de governança à medida que novos serviços são disponibilizados. 

 **Etapas da implementação** 

1.  Identifique as partes interessadas referentes à sua workload, incluindo quaisquer equipes centralizadas. 

1.  Trabalhe com as partes interessadas para identificar requisitos de governança. 

1.  Assim que gerar uma lista, priorize os itens de melhoria e comece a implementá-los na workload. 

   1.  Use serviços como o [AWS Config](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/) para criar governança como código e validar se esses requisitos de governança são seguidos. 

   1.  Se usar o [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), poderá utilizar políticas de controle de serviços para implementar requisitos de governança. 

1.  Forneça uma documentação que valide a implementação. 

 **Nível de esforço do plano de implementação:** médio. A implementação de requisitos de governança pode exigir a reformulação de sua workload. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS01-BP04 Avaliar os requisitos de conformidade](ops_priorities_compliance_reqs.md): a conformidade é como a governança, mas provém de fora da organização. 

 **Documentos relacionados:** 
+ [ Guia de gerenciamento e governança do ambiente de nuvem da AWS](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/management-and-governance-cloud-environment-guide.html)
+ [ Práticas recomendadas para políticas de controle de serviço do AWS Organizations](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ Governança na Nuvem AWS: o equilíbrio entre agilidade e segurança ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
+ [ O que é governança, risco e conformidade (GRC)? ](https://aws.amazon.com/what-is/grc/)

 **Vídeos relacionados:** 
+ [ Gerenciamento e governança da AWS: configuração, conformidade e auditoria – AWS Online Tech Talks ](https://www.youtube.com/watch?v=79ud1ZAaoj0)
+ [AWS re:Inforce 2019: Governança da era da nuvem (DEM12-R1) ](https://www.youtube.com/watch?v=y3WmHnavuN8)
+ [AWS re:Invent 2020: Como alcançar a conformidade usando o AWS Config](https://www.youtube.com/watch?v=m8vTwvbzOfw)
+ [AWS re:Invent 2020: Governança ágil na AWS GovCloud (US)](https://www.youtube.com/watch?v=hv6B17eriHQ)

 **Exemplos relacionados:** 
+ [ Amostras de pacote de conformidade do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/conformancepack-sample-templates.html)

 **Serviços relacionados:** 
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Organizations: políticas de controle de serviços ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)

# OPS01-BP04 Avaliar os requisitos de conformidade
<a name="ops_priorities_compliance_reqs"></a>

Os requisitos de conformidade normativos, setoriais e internos são um importante motivador para definir as prioridades de sua organização. Seu framework de conformidade pode impedir você de usar tecnologias ou localizações geográficas específicas. Realize a devida diligência se não for identificado nenhum framework de conformidade externo. Gere auditorias ou relatórios que validem a conformidade.

 Se você anunciar que seu produto atende a padrões de conformidade específicos, deverá ter um processo interno para garantir a conformidade contínua. Os exemplos de padrões de conformidade incluem o PCI DSS, o FedRAMP e a HIPAA. Os padrões de conformidade aplicáveis são determinados por vários fatores, por exemplo, quais tipos de dados a solução armazena ou transmite e a quais regiões a solução oferece suporte. 

 **Resultado desejado:** 
+  Os requisitos de conformidade normativos, setoriais e internos são incorporados na seleção arquitetural. 
+  Você pode validar a conformidade e gerar relatórios de auditoria. 

 **Antipadrões comuns:** 
+ Partes da workload enquadram-se no framework Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI-DSS), mas a workload armazena dados de cartões de crédito não criptografados.
+ Seus desenvolvedores e arquitetos de software não estão a par do framework de conformidade que sua organização deve adotar.
+  A auditoria anual de Controle de Sistemas e Organizações: Tipo II (SOC2) será feita em breve e você não consegue verificar se esses controles estão em vigor. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Avaliar e compreender os requisitos de conformidade que se aplicam à sua workload informará como você prioriza seus esforços para entregar valor empresarial. 
+  Você escolhe as localizações e tecnologias corretas, que são congruentes com seu framework de conformidade. 
+  Quando a workload é projetada para ser auditável, você tem a possibilidade de provar que está seguindo seu framework de conformidade. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Implementar essa prática recomendada significa incorporar os requisitos de conformidade no processo de design da arquitetura. Os membros de sua equipe estão a par do framework de conformidade necessário. Você valida a conformidade de acordo com o framework. 

 **Exemplo de clientes** 

 A Loja UmaEmpresa armazena informações de cartão de crédito dos clientes. Os desenvolvedores da equipe de armazenamento de cartões sabem que eles precisam acatar o framework PCI-DSS. Eles tomaram medidas para verificar que as informações de cartão de crédito são armazenadas e acessadas com segurança, de acordo com o framework PCI-DSS. Todo ano, eles trabalham com a equipe de segurança para validar a conformidade. 

 **Etapas da implementação** 

1.  Trabalhe com as equipes de segurança e governança para determinar quais frameworks de conformidade normativos, setoriais ou internos a workload deve seguir. Incorpore os frameworks de conformidade em sua workload. 

   1.  Valide a conformidade contínua dos recursos da AWS com serviços como o [AWS Compute Optimizer](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) e o [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html). 

1.  Instrua os membros da equipe sobre os requisitos de conformidade para que possam operar e expandir a workload de acordo com eles. Os requisitos de conformidade devem ser incluídos nas escolhas de arquitetura e tecnologia. 

1.  Dependendo do framework de conformidade, pode ser necessário gerar um relatório de auditoria ou conformidade. Trabalhe com sua organização para automatizar esse processo o máximo possível. 

   1.  Use serviços como o [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) para validar a conformidade e gerar relatórios de auditoria. 

   1.  Você pode baixar documentos de segurança e conformidade da AWS com o [AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html). 

 **Nível de esforço do plano de implementação:** médio. A implementação de frameworks de conformidade pode ser um desafio. A geração de relatórios de auditoria e de documentos de conformidade aumenta ainda mais complexidade. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC01-BP03 Identificar e validar objetivos de controle](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html): os objetivos de controle de segurança são uma parte importante da conformidade geral. 
+  [SEC01-BP06 Automatizar testes e validar controles de segurança em pipelines](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_test_validate_pipeline.html): como parte de seus pipelines, validade os controles de segurança. Você também pode gerar documentação de conformidade para novas mudanças. 
+  [SEC07-BP02 Definir controles de proteção de dados](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_define_protection.html): muitos frameworks de conformidade têm políticas baseadas em processamento e armazenamento de dados. 
+  [SEC10-BP03 Preparar recursos forenses](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_prepare_forensic.html): às vezes é possível usar recursos forenses em auditoria de conformidade. 

 **Documentos relacionados:** 
+ [ Centro de Conformidade da AWS](https://aws.amazon.com/financial-services/security-compliance/compliance-center/)
+ [ Recursos de conformidade da AWS](https://aws.amazon.com/compliance/resources/)
+ [ Whitepaper AWS: risco e conformidade](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [Modelo de Responsabilidade Compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [ Serviços da AWS no escopo por programa de conformidade ](https://aws.amazon.com/compliance/services-in-scope/)

 **Vídeos relacionados:** 
+ [AWS re:Invent 2020:Como alcançar a conformidade usando o AWS Compute Optimizer](https://www.youtube.com/watch?v=m8vTwvbzOfw)
+ [AWS re:Invent 2021: Conformidade, garantia e auditoria ](https://www.youtube.com/watch?v=pdrYGVgb08Y)
+ [AWS Summit ATL 2022: Implementação de conformidade, garantia e auditoria na AWS (COP202) ](https://www.youtube.com/watch?v=i7XrWimhqew)

 **Exemplos relacionados:** 
+ [PCI DSS e Práticas recomendadas de segurança básica da AWS na AWS](https://aws.amazon.com/solutions/partners/compliance-pci-fsbp-remediation/)

 **Serviços relacionados:** 
+ [AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html)
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html)
+ [AWS Compute Optimizer](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)

# OPS01-BP05 Avaliar o cenário de ameaças
<a name="ops_priorities_eval_threat_landscape"></a>

 Avalie as ameaças à empresa (por exemplo, concorrência, risco e passivos empresariais, riscos operacionais e ameaças à segurança da informação) e mantenha as informações atuais em um registro de risco. Inclua o impacto dos riscos ao determinar onde concentrar os esforços. 

 O [Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) enfatiza o aprendizado, a medição e a melhoria. Ele fornece uma abordagem consistente para avaliar arquiteturas e implementar projetos que aumentarão em escala verticalmente ao longo do tempo. A AWS fornece o [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/) para ajudar você a analisar sua abordagem antes do desenvolvimento, o estado das cargas de trabalho antes da produção e o estado das cargas de trabalho na produção. Você pode compará-los com as práticas recomendadas de arquitetura mais recentes da AWS, monitorar o status geral das workloads e obter insights sobre possíveis riscos. 

 Os clientes da AWS estão qualificados para uma revisão orientada pelo Well-Architected de suas workloads de essenciais para [medir a arquitetura deles](https://aws.amazon.com/premiumsupport/programs/) em relação às práticas recomendadas da AWS. Os clientes do Enterprise Support estão qualificados para uma [Revisão de operações](https://aws.amazon.com/premiumsupport/programs/), projetada para ajudá-los a identificar lacunas em sua abordagem de operação na nuvem. 

 O envolvimento entre equipes dessas avaliações ajuda a estabelecer um entendimento comum de suas cargas de trabalho e como as funções da equipe contribuem para o sucesso. As necessidades identificadas pela avaliação podem ajudar a moldar suas prioridades. 

 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) é uma ferramenta que fornece acesso a um conjunto principal de verificações que recomendam otimizações que podem ajudar a moldar suas prioridades. [Os clientes Business e Enterprise Support](https://aws.amazon.com/premiumsupport/plans/) recebem acesso a verificações adicionais com foco em segurança, confiabilidade, performance e otimização de custos que podem ajudar a moldar suas prioridades. 

 **Antipadrões comuns:** 
+  Você está usando uma versão antiga de uma biblioteca de software no seu produto. Você não está ciente das atualizações de segurança na biblioteca para problemas que podem ter um impacto indesejado na carga de trabalho. 
+  Seu concorrente acabou de lançar uma versão do produto que lida com muitas das reclamações de seus clientes sobre seu produto. Você não priorizou a abordagem de nenhum desses problemas conhecidos. 
+  Os reguladores buscam empresas como a sua que não estejam em conformidade com os requisitos de conformidade normativa legais. Você não priorizou a abordagem de nenhum de seus requisitos de conformidade pendentes. 

 **Benefícios do estabelecimento desta prática recomendada:** Identificar e compreender as ameaças à sua organização e carga de trabalho permite determinar quais ameaças devem ser resolvidas, a prioridade delas e os recursos necessários para isso. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Avaliar o cenário de ameaças aos negócios: avalie as ameaças aos negócios (como concorrência, riscos e responsabilidades comerciais, riscos operacionais e ameaças à segurança das informações), para que você possa incluir o impacto dessas ameaças ao determinar onde concentrar esforços. 
  +  [Boletins de segurança mais recentes da AWS](https://aws.amazon.com/security/security-bulletins/) 
  +  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
  +  Manter um modelo de ameaças: estabeleça e mantenha um modelo de ameaças que identifique possíveis ameaças, mitigações planejadas e implementadas e a prioridade delas. Analise a probabilidade de as ameaças se manifestarem como incidentes, o custo de recuperação desses incidentes, o dano esperado causado e o custo para evitar esses incidentes. Revise as prioridades à medida que o conteúdo do modelo de ameaça muda. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Conformidade da Nuvem AWS](https://aws.amazon.com/compliance/) 
+  [Boletins de segurança mais recentes da AWS](https://aws.amazon.com/security/security-bulletins/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 

# OPS01-BP06 Avalie as compensações
<a name="ops_priorities_eval_tradeoffs"></a>

 Avalie o impacto das compensações entre interesses concorrentes ou abordagens alternativas para ajudar a tomar decisões embasadas ao determinar onde concentrar os esforços ou escolher um plano de ação. Por exemplo, a aceleração da velocidade de entrada no mercado de novos recursos pode ser enfatizada em relação à otimização de custos, ou você pode escolher um banco de dados relacional para dados não relacionais para simplificar o esforço de migração de um sistema, em vez de migrar para um banco de dados otimizado para seu tipo de dados e atualizar seu aplicativo. 

 A AWS pode ajudar a educar suas equipes sobre a AWS e seus serviços para aumentar a compreensão de como suas escolhas podem ter um impacto na workload. Você deve usar os recursos fornecidos pelo [AWS Support](https://aws.amazon.com/premiumsupport/programs/) ([Centro de Conhecimentos da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/), [Fóruns de discussão da AWS](https://forums.aws.amazon.com/index.jspa)e [AWS Support Center](https://console.aws.amazon.com/support/home/)) e pela [documentação da AWS](https://docs.aws.amazon.com/) para instruir suas equipes. Entre em contato com o AWS Support por meio do AWS Support Center para obter ajuda com relação às suas dúvidas sobre a AWS. 

 A AWS também compartilha as práticas recomendadas e os padrões que aprendemos durante a operação da AWS na [Amazon Builders’ Library](https://aws.amazon.com/builders-library/). Uma variedade de outras informações úteis está disponível no [Blog da AWS](https://aws.amazon.com/blogs/) e [O podcast oficial da AWS](https://aws.amazon.com/podcasts/aws-podcast/). 

 **Antipadrões comuns:** 
+  Você está usando um banco de dados relacional para gerenciar séries temporais e dados não relacionais. Existem opções de banco de dados otimizadas para oferecer suporte aos tipos de dados que você está usando, mas você não tem conhecimento dos benefícios, pois não avaliou as compensações entre soluções. 
+  Seus investidores solicitam que você demonstre conformidade com os Padrões de segurança de dados do setor de cartões de pagamento (PCI DSS). Você não considera as compensações entre atender à solicitação deles e continuar com seus esforços de desenvolvimento atuais. Em vez disso, prossiga com seus esforços de desenvolvimento sem demonstrar conformidade. Seus investidores interrompem o suporte da sua empresa devido a preocupações com a segurança da sua plataforma e com os investimentos deles. 

 **Benefícios do estabelecimento desta prática recomendada:** Entender as implicações e as consequências de suas escolhas permite que você priorize suas opções. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Avaliar as compensações: avalie o impacto das compensações entre as partes interessadas concorrentes para ajudar a tomar decisões embasadas ao determinar onde concentrar esforços. Por exemplo, a aceleração da velocidade de introdução no mercado de novos recursos pode ser enfatizada sobre a otimização de custos. 
+  A AWS pode ajudar a educar suas equipes sobre a AWS e seus serviços para aumentar a compreensão de como suas escolhas podem ter um impacto na workload. Use os recursos fornecidos pelo AWS Support (Centro de Conhecimentos da AWS, Fóruns de discussão da AWS e AWS Support Center) e pela documentação da AWS para instruir suas equipes. Entre em contato com o AWS Support por meio do AWS Support Center para obter ajuda com relação às suas dúvidas sobre a AWS. 
+  A AWS também compartilha as práticas recomendadas e os padrões que aprendemos durante a operação da AWS na Amazon Builders' Library. Uma grande variedade de outras informações úteis está disponível no Blog da AWS e no podcast oficial da AWS. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Blog da AWS](https://aws.amazon.com/blogs/) 
+  [Conformidade da Nuvem AWS](https://aws.amazon.com/compliance/) 
+  [Fóruns de discussão da AWS](https://forums.aws.amazon.com/index.jspa) 
+  [documentação da AWS](https://docs.aws.amazon.com/) 
+  [Centro de Conhecimentos da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [AWS Support](https://aws.amazon.com/premiumsupport/) 
+  [AWS Support Center](https://console.aws.amazon.com/support/home/) 
+  [Amazon Builders’ Library](https://aws.amazon.com/builders-library/) 
+  [O podcast oficial da AWS](https://aws.amazon.com/podcasts/aws-podcast/) 

# OPS01-BP07 Gerenciar os benefícios e os riscos
<a name="ops_priorities_manage_risk_benefit"></a>

 Gerencie benefícios e riscos para tomar decisões informadas ao determinar onde concentrar os esforços. Pode ser benéfico, por exemplo, implantar uma carga de trabalho com problemas não resolvidos a fim de disponibilizar recursos novos e significativos aos clientes. Talvez seja possível mitigar os riscos associados ou talvez seja inaceitável permitir que um risco permaneça; nesse caso, você tomará as devidas medidas para resolver o risco. 

 Em determinado momento, talvez você deseje destacar um pequeno subconjunto de prioridades. Use uma abordagem equilibrada em longo prazo para garantir o desenvolvimento dos recursos necessários e o gerenciamento de riscos. Atualize suas prioridades conforme as necessidades mudam 

 **Antipadrões comuns:** 
+  Um de seus desenvolvedores encontrou na Internet, uma biblioteca que faz tudo o que você precisa, e você decidiu incluí-la. Você não avaliou os riscos de adoção dessa biblioteca de uma origem desconhecida e não sabe se ela contém vulnerabilidades ou código mal-intencionado. 
+  Você decidiu desenvolver e implantar um novo recurso em vez de corrigir um problema existente. Você não avaliou os riscos de continuar com o problema até que o recurso seja implantado e não sabe qual será o impacto nos seus clientes. 
+  Você decidiu não implantar um recurso solicitado frequentemente pelos clientes devido a preocupações não especificadas da sua equipe de conformidade. 

 **Benefícios do estabelecimento desta prática recomendada:** Identificar os benefícios disponíveis das suas escolhas e estar ciente dos riscos para a sua organização permite que você tome decisões bem embasadas. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Gerenciar os benefícios e os riscos: equilibre os benefícios das decisões em relação aos riscos envolvidos. 
  +  Identificar os benefícios: identifique os benefícios com base nas metas, necessidades e prioridades da empresa. Os exemplos incluem tempo de colocação no mercado, segurança, confiabilidade, performance e custo. 
  +  Identificar os riscos: identifique os riscos com base nas metas, necessidades e prioridades da empresa. Os exemplos incluem tempo de colocação no mercado, segurança, confiabilidade, performance e custo. 
  +  Avaliar os benefícios em relação aos riscos e tomar decisões embasadas: determine o impacto dos benefícios e dos riscos com base nas metas, necessidades e prioridades das principais partes interessadas, incluindo os negócios, o desenvolvimento e as operações. Avalie o valor do benefício em relação à probabilidade de realização do risco e o custo do seu impacto. Por exemplo, enfatizar a velocidade de entrada no mercado em vez da confiabilidade pode oferecer vantagem competitiva. No entanto, isso pode resultar em tempo de atividade reduzido se houver problemas de confiabilidade. 

# OPERAÇÕES 2. Como estruturar sua organização para dar suporte aos resultados comerciais?
<a name="ops-02"></a>

 Suas equipes devem compreender o papel delas na obtenção de resultados empresariais. As equipes devem entender o papel delas no êxito de outras equipes, a função das outras equipes no êxito delas, e ter objetivos compartilhados. Entender a responsabilidade, a propriedade, como as decisões são tomadas e quem tem autoridade para tomar decisões ajudará a concentrar os esforços e maximizar os benefícios das suas equipes. 

**Topics**
+ [OPS02-BP01 Recursos com proprietários identificados](ops_ops_model_def_resource_owners.md)
+ [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md)
+ [OPS02-BP03 Atividades de operações com proprietários identificados responsáveis pela performance](ops_ops_model_def_activity_owners.md)
+ [OPS02-BP04 Os membros da equipe sabem pelo que são responsáveis](ops_ops_model_know_my_job.md)
+ [OPS02-BP05 Existem mecanismos para identificar a responsabilidade e a propriedade](ops_ops_model_find_owner.md)
+ [OPS02-BP06 Mecanismos existem para solicitar adições, alterações e exceções](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP07 As responsabilidades entre as equipes são predefinidas ou negociadas](ops_ops_model_def_neg_team_agreements.md)

# OPS02-BP01 Recursos com proprietários identificados
<a name="ops_ops_model_def_resource_owners"></a>

Os recursos para sua workload devem ter proprietários identificados para controle de alterações, resolução de problemas e outras funções. Atribuem-se proprietários para workloads, contas, infraestrutura, plataformas e aplicações. A propriedade é registrada usando ferramentas como um registro central ou metadados anexados aos recursos. O valor empresarial dos componentes indica os processos e procedimentos aplicados a eles.

 **Resultado desejado:** 
+  Os recursos têm proprietários identificados usando metadados ou um registro central. 
+  Os membros da equipe podem identificar quem é proprietários dos recursos. 
+  As contas têm um único proprietário quando possível. 

 **Antipadrões comuns:** 
+  Os contatos alternativos para suas Contas da AWS não estão preenchidos. 
+  Os recursos não têm as tags que identificam as equipes às quais eles pertencem. 
+  Você tem uma fila ITSM sem mapeamento de e-mail. 
+  Duas equipes são proprietárias de uma mesma parte essencial da infraestrutura. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  O controle de alterações para recursos é fácil com a atribuição de propriedade. 
+  Você pode envolver os proprietários corretos na resolução de problemas. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Defina o que significa propriedade para os casos de uso de recursos em seu ambiente. A propriedade pode se referir a quem supervisiona alterações no recurso e apoia o recurso durante a resolução de problemas ou a quem é responsável pela parte financeira. Especifique e registre proprietários para recursos, incluindo nome, informações de contato, organização e equipe. 

 **Exemplo de clientes** 

 A Loja UmaEmpresa define propriedade como a equipe ou a pessoa proprietária das alterações e do suporte para os recursos. Eles utilizam o AWS Organizations para gerenciar as Contas da AWS. Os contatos de conta alternativos são configurados usando as caixas de entrada de grupo. Cada fila ITSM é mapeada para um alias de e-mail. As tags identificam quem é proprietário dos recursos da AWS. Para outras plataformas e infraestrutura, eles têm uma página de wiki que identifica informações sobre propriedade e contato. 

 **Etapas da implementação** 

1.  Para começar, identifique a propriedade sobre sua organização. A propriedade pode estar relacionada a quem é proprietário do risco referente ao recurso, a quem é proprietário das alterações referentes ao recurso ou a quem apoia o recurso na resolução de problemas. Propriedade também pode significar propriedade financeira ou administrativa pelo recurso. 

1.  Use o [AWS Organizations](https://aws.amazon.com/organizations/) para gerenciar contas. Você pode gerenciar contatos alternativos centralmente para as suas contas. 

   1.  O uso de endereços de e-mail ou de números de telefones de propriedade da empresa para informações de contato permite acessá-los mesmo quando os indivíduos aos quais eles pertencem não estiverem mais na organização. Por exemplo, crie listas de distribuição de e-mail separadas para faturamento, operações e segurança, e configure-as como contatos de Faturamento, Segurança e Operações em cada Conta da AWS ativa. Várias pessoas receberão notificações da AWS e poderão respondê-las, mesmo que alguém esteja de férias, mude de função ou saia da empresa. 

   1.  Se uma conta não for gerenciada pelo [AWS Organizations](https://aws.amazon.com/organizations/), os contatos alternativos para contas ajudarão a AWS a entrar em contato com o pessoal apropriado, se necessário. Configure os contatos alternativos da conta para apontar para um grupo em vez de uma pessoa. 

1.  Use tags para identificar proprietários de recursos da AWS. Você pode especificar os proprietários e as respectivas informações de contato em tags separadas. 

   1.  Pode usar regras do [AWS Config](https://aws.amazon.com/config/) para reforçar que os recursos têm as tags de propriedade necessárias. 

   1.  Para obter orientações detalhadas sobre como elaborar uma estratégia de marcação para sua organização, consulte o [whitepaper Práticas recomendadas de marcação da AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). 

1.  Para outros recursos, plataformas e infraestrutura, crie uma documentação que identifique a propriedade. Ela deve ser acessível a todos os membros da equipe. 

 **Nível de esforço do plano de implementação:** baixo. Utilize informações de contato da conta e tags para atribuir propriedade a recursos da AWS. Para outros recursos, você pode usar algo simples como uma tabela em uma wiki para registrar a propriedade e informações de contato ou usar uma ferramenta de ITSM para mapear a propriedade. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md): os processos e procedimentos para apoiar os recursos dependem do proprietário do recurso. 
+  [OPS02-BP04 Os membros da equipe sabem pelo que são responsáveis](ops_ops_model_know_my_job.md): os membros da equipe devem saber de quais recursos eles são proprietários. 
+  [OPS02-BP05 Existem mecanismos para identificar a responsabilidade e a propriedade](ops_ops_model_find_owner.md): é necessário usar mecanismos como tags e contatos de conta para que a propriedade possa ser descoberta. 

 **Documentos relacionados:** 
+ [AWS Account Management: Atualizar informações de contato](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html#manage-acct-update-contact-alternate-edit.html)
+ [Regras do AWS Config: required-tags ](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)
+ [AWS Organizations: Atualizar contatos alternativos em sua organização ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_contacts.html)
+  [Whitepaper Práticas recomendadas de marcação AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) 

 **Exemplos relacionados:** 
+ [ Regras do AWS Config: Amazon EC2 com regras requeridas e valores válidos ](https://github.com/awslabs/aws-config-rules/blob/master/python/ec2_require_tags_with_valid_values.py)

 **Serviços relacionados:** 
+  [AWS Config](https://aws.amazon.com/config/) 
+  [AWS Organizations](https://aws.amazon.com/organizations/) 

# OPS02-BP02 Processos e procedimentos com proprietários identificados
<a name="ops_ops_model_def_proc_owners"></a>

 Entenda quem tem a propriedade da definição de processos e procedimentos individuais, por que esses processos e procedimentos específicos são usados e por que essa propriedade existe. Entender os motivos pelos quais processos e procedimentos específicos são usados permite identificar oportunidades de melhoria. 

 **Benefícios do estabelecimento desta prática recomendada:** Entender a propriedade identifica quem pode aprovar melhorias, implementar essas melhorias ou ambos. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Processos e procedimentos com proprietários identificados responsáveis pela sua definição: capture os processos e procedimentos usados em seu ambiente e o indivíduo ou a equipe responsável pela sua definição. 
  +  Identifique processos e procedimentos: identifique as atividades de operações realizadas para dar suporte às suas workloads. Documente essas atividades em um local que possa ser localizado. 
  +  Defina quem é o proprietário de um processo ou procedimento: identifique exclusivamente o indivíduo ou a equipe responsável pela especificação de uma atividade. Eles são responsáveis por garantir que ela possa ser executada com êxito por um membro da equipe devidamente qualificado com as permissões, as ferramentas e o acesso corretos. Se houver problemas com a execução dessa atividade, os membros da equipe que a executam serão responsáveis por fornecer os comentários detalhados necessários para que a atividade seja melhorada. 
  +  Capture a propriedade de artefato de atividades nos metadados: os procedimentos automatizados em serviços como o AWS Systems Manager, por meio de documentos, e o AWS Lambda, como funções, são compatíveis com a captura de informações de metadados como tags. Capture a propriedade de recursos usando tags ou grupos de recursos, especificando propriedade e informações de contato. Use o AWS Organizations para criar políticas de marcação e garantir que as informações de propriedade e de contato sejam capturadas. 

# OPS02-BP03 Atividades de operações com proprietários identificados responsáveis pela performance
<a name="ops_ops_model_def_activity_owners"></a>

 Entenda quem tem a responsabilidade de realizar atividades específicas em cargas de trabalho definidas e por que essa responsabilidade existe. Entender quem tem a responsabilidade de realizar atividades informa quem realizará a atividade, validará o resultado e fornecerá feedback ao proprietário da atividade. 

 **Benefícios do estabelecimento desta prática recomendada:** Entender quem é responsável por realizar uma atividade informa a quem notificar quando uma ação é necessária e quem executará a ação, validará o resultado e fornecerá feedback ao proprietário da atividade. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Atividades de operações com proprietários identificados responsáveis por sua performance: capture a responsabilidade por executar processos e procedimentos usados em seu ambiente. 
  +  Identificar processos e procedimentos: identifique as atividades de operações realizadas para dar suporte às suas workloads. Documente essas atividades em um local que possa ser localizado. 
  +  Definir quem é responsável por executar cada atividade: identifique a equipe responsável por uma atividade. Certifique-se de que eles tenham os detalhes da atividade e as habilidades necessárias e as permissões, as ferramentas e o acesso corretos para realizar a atividade. Eles devem compreender a condição sob a qual ela deve ser executada (por exemplo, em um evento ou programação). Torne essas informações detectáveis para que os membros da sua organização possam identificar com quem precisam entrar em contato, equipe ou indivíduo, para necessidades específicas. 

# OPS02-BP04 Os membros da equipe sabem pelo que são responsáveis
<a name="ops_ops_model_know_my_job"></a>

 Entender as responsabilidades de sua função e como você contribui para resultados comerciais informa a priorização de suas tarefas e por que sua função é importante. Isso permite que os membros da equipe reconheçam as necessidades e respondam adequadamente. 

 **Benefícios do estabelecimento desta prática recomendada:** entender suas responsabilidades fundamenta as decisões que você toma, as ações que você realiza e suas atividades de entrega aos proprietários apropriados. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Garantir que os membros da equipe compreendam suas funções e responsabilidades: identifique as funções e responsabilidades dos membros da equipe e garanta que eles compreendam as expectativas da função que exercem. Torne essas informações detectáveis para que os membros da sua organização possam identificar com quem precisam entrar em contato, equipe ou indivíduo, para necessidades específicas. 

# OPS02-BP05 Existem mecanismos para identificar a responsabilidade e a propriedade
<a name="ops_ops_model_find_owner"></a>

 Quando nenhum indivíduo ou equipe é identificado, há caminhos de escalonamento definidos para alguém com autoridade para atribuir propriedade ou plano para o que precisa ser abordado. 

 **Benefícios do estabelecimento desta prática recomendada:** Entender quem tem responsabilidade ou propriedade permite que você entre em contato com a equipe ou o membro da equipe apropriado para fazer uma solicitação ou a transição de uma tarefa. Ter uma pessoa identificada que tenha a autoridade para atribuir responsabilidade ou propriedade ou planejar atender às necessidades, reduz o risco de inação, além de não ser preciso lidar com isso. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Mecanismos existentes para identificar a responsabilidade e a propriedade: forneça mecanismos acessíveis para que os membros da sua organização descubram e identifiquem a propriedade e a responsabilidade. Esses mecanismos permitirão que eles identifiquem com quem entrar em contato, equipe ou indivíduo, em caso de necessidades específicas. 

# OPS02-BP06 Mecanismos existem para solicitar adições, alterações e exceções
<a name="ops_ops_model_req_add_chg_exception"></a>

Você pode fazer solicitações aos proprietários de processos, procedimentos e recursos. Solicitações incluem adições, alterações e exceções. Essas solicitações passam por um processo de gerenciamento de alterações. Tome decisões embasadas para aprovar solicitações quando elas forem viáveis e foram consideradas apropriadas após uma avaliação de benefícios e riscos. 

 **Resultado desejado:** 
+  Você pode fazer solicitações para alterar processos, procedimentos e recursos com base na propriedade atribuída. 
+  As alterações são feitas de maneira deliberada, ponderando benefícios e riscos. 

 **Antipadrões comuns:** 
+  Você precisa atualizar a maneira como implanta sua aplicação, mas não há como solicitar uma alteração no processo de implantação à equipe de operações. 
+  O plano de recuperação de desastres deve ser atualizado, mas não há nenhum proprietário identificado para solicitar alterações no plano. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Processos, procedimentos e recursos podem evoluir à medida que os requisitos mudam. 
+  Os proprietários podem tomar decisões embasadas sobre quando realizar alterações. 
+  As alterações são feitas de maneira deliberada. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Para implementar esta prática recomendada, você precisa estar em uma posição em que possa solicitar alterações em processos, procedimentos e recursos. O processo de gerenciamento de alterações pode ser simples. Documente o processo de gerenciamento de alterações. 

 **Exemplo de clientes** 

 A Loja UmaEmpresa usa a matriz de atribuição de responsabilidades (RACI) para identificar quem é proprietário das alterações em processos, procedimentos e recursos. Eles documentaram o processo de gerenciamento de alterações, que é simples e fácil de seguir. Usando a matriz RACI e o processo, qualquer pessoa pode enviar solicitações de alteração. 

 **Etapas da implementação** 

1.  Identifique processos, procedimentos e recursos para sua workload e os proprietários de cada um. Documente-os no sistema de gerenciamento de conhecimentos. 

   1.  Se você não tiver implementado [OPS02-BP01 Recursos com proprietários identificados](ops_ops_model_def_resource_owners.md), [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md) ou [OPS02-BP03 Atividades de operações com proprietários identificados responsáveis pela performance](ops_ops_model_def_activity_owners.md), comece com estes. 

1.  Trabalhe com as partes interessadas em sua organização para desenvolver um processo de gerenciamento de alterações. O processo deve abranger adições, alterações e exceções para recursos, processos e procedimentos. 

   1.  Você pode usar o [Gerente de Alterações do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html) como plataforma de gerenciamento de alterações para recursos de workload. 

1.  Documente o processo de gerenciamento de alterações em seu sistema de gerenciamento de conhecimentos. 

 **Nível de esforço do plano de implementação:** médio. O desenvolvimento de um processo de gerenciamento de alterações deve estar alinhado com várias partes interessadas em sua organização. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS02-BP01 Recursos com proprietários identificados](ops_ops_model_def_resource_owners.md): para criar um processo de gerenciamento de alterações, primeiro é necessário identificar os proprietários dos recursos. 
+  [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md): para criar um processo de gerenciamento de alterações, primeiro é necessário identificar os proprietários dos recursos. 
+  [OPS02-BP03 Atividades de operações com proprietários identificados responsáveis pela performance](ops_ops_model_def_activity_owners.md): para criar um processo de gerenciamento de alterações, primeiro é necessário identificar os proprietários. 

 **Documentos relacionados:** 
+ [AWS Prescriptive Guidance - Foundation playbook for AWS large migrations: Creating RACI matrices ](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html#raci)
+ [ Whitepaper Gerenciamento de alterações na nuvem ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)

 **Serviços relacionados:** 
+ [Gerente de Alterações do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)

# OPS02-BP07 As responsabilidades entre as equipes são predefinidas ou negociadas
<a name="ops_ops_model_def_neg_team_agreements"></a>

Tenha acordos definidos ou negociados entre as equipes que descrevam como elas trabalham e oferecem suporte umas às outras (por exemplo, tempos de resposta, objetivos de nível de serviço ou Acordos de Serviço). Os canais de comunicação entre equipes são documentados. Ao entender o impacto do trabalho das equipes nos resultados de negócios e nos resultados de outras equipes e organizações, você conhece a priorização de tarefas delas e as ajuda a responder adequadamente. 

 Quando a responsabilidade e a propriedade não foram definidas ou são desconhecidas, você corre o risco de não abordar as atividades necessárias em tempo hábil e de despender esforços redundantes e possivelmente conflitantes para atender a essas necessidades. 

 **Resultado desejado:** 
+  Os acordos de trabalho ou apoio entre equipes são combinados e documentados. 
+  As equipes que apoiam ou trabalham umas com as outras definiram canais de comunicação e expectativas de resposta. 

 **Antipadrões comuns:** 
+  Ocorre um problema na produção e duas equipes separadas começam iniciam a resolução de problemas de maneira independente. Esses esforços isolados estendem a interrupção. 
+  A equipe de operações necessita de assistência da equipe de desenvolvimento, mas nenhum tempo de resposta foi acordado. A solicitação está parada em uma lista de pendências. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  As equipes sabem interagir e apoiar uma à outra. 
+  As expectativas quanto à capacidade de resposta são claras. 
+  Os canais de comunicação estão nitidamente definidos. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 A implementação desta prática recomendada significa que não há ambiguidade quanto à forma como as equipes trabalham uma com a outra. Os acordos formais sistematizam de que maneira as equipes trabalham juntas ou apoiam uma à outra. Os canais de comunicação entre as equipes são documentados. 

 **Exemplo de clientes** 

 A equipe de SRE da Loja UmaEmpresa tem um Acordo de Serviço com a equipe de desenvolvimento. Sempre que a equipe de desenvolvimento faz uma solicitação no sistema de tíquetes, ela pode esperar uma resposta em 15 minutos. Se não houver nenhuma interrupção no local, a equipe de SRE toma a dianteira na investigação e conta com o apoio da equipe de desenvolvimento. 

 **Etapas da implementação** 

1.  Trabalhando com as partes interessadas na organização, desenvolva acordos entre as equipes com base nos processos e procedimentos. 

   1.  Se um processo ou procedimento for compartilhado entre as duas equipes, desenvolva um runbook sobre como as equipes trabalharão juntas. 

   1.  Se houver dependências entre as equipes, estabeleça um SLA de resposta às solicitações. 

1.  Documente as responsabilidades no sistema de gerenciamento de conhecimentos. 

 **Nível de esforço do plano de implementação:** médio. Se não houver nenhum entendimento entre as equipes, pode ser difícil chegar a um acordo com as partes interessadas na organização. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md): para estabelecer acordos entre as equipes, primeiro é necessário identificar o proprietário do processo. 
+  [OPS02-BP03 Atividades de operações com proprietários identificados responsáveis pela performance](ops_ops_model_def_activity_owners.md): para estabelecer acordos entre as equipes, primeiro é necessário identificar o proprietário das atividades de operações. 

 **Documentos relacionados:** 
+ [AWS Executive Insights: Impulsionando inovação e velocidade com as equipes de duas pizzas da Amazon ](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [ Introdução a DevOps na AWS: Equipes de duas pizzas) ](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)

# OPERAÇÕES 3. Como sua cultura organizacional oferece suporte aos resultados comerciais?
<a name="ops-03"></a>

 Forneça suporte aos membros da equipe para que eles possam ser mais eficazes na tomada de ações e no suporte aos resultados comerciais. 

**Topics**
+ [OPS03-BP01 Patrocínio executivo](ops_org_culture_executive_sponsor.md)
+ [OPS03-BP02 Os membros da equipe estão capacitados para executar ações quando os resultados estão em risco.](ops_org_culture_team_emp_take_action.md)
+ [OPS03-BP03 Incentivo ao escalonamento](ops_org_culture_team_enc_escalation.md)
+ [OPS03-BP04 Comunicações oportunas, claras e acionáveis](ops_org_culture_effective_comms.md)
+ [OPS03-BP05 Incentivo à experimentação](ops_org_culture_team_enc_experiment.md)
+ [OPS03-BP06 Os membros da equipe estão capacitados e são incentivados a manter e a aumentar seus conjuntos de habilidades.](ops_org_culture_team_enc_learn.md)
+ [OPS03-BP07 Fornecer recursos adequados às equipes](ops_org_culture_team_res_appro.md)
+ [OPS03-BP08 Opiniões diversas são incentivadas e procuradas dentro e entre equipes](ops_org_culture_diverse_inc_access.md)

# OPS03-BP01 Patrocínio executivo
<a name="ops_org_culture_executive_sponsor"></a>

 A liderança sênior define claramente as expectativas para a organização e avalia o êxito. A liderança sênior é patrocinadora, defensora e motivadora da adoção das melhores práticas e da evolução da organização 

 **Benefícios do estabelecimento desta prática recomendada:** A liderança engajada, as expectativas comunicadas claramente e as metas compartilhadas garantem que os membros da equipe saibam o que se espera deles. A avaliação do sucesso possibilita a identificação de barreiras para o sucesso, para que elas possam ser abordadas por meio da intervenção do patrocinador ou dos representantes dele. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Patrocínio executivo: a liderança sênior define claramente as expectativas para a organização e avalia o êxito. A liderança sênior é patrocinadora, defensora e motivadora da adoção das melhores práticas e da evolução da organização 
  +  Definir as expectativas: defina e publique metas para suas organizações, incluindo como elas serão medidas. 
  +  Monitorar a concretização das metas: meça regularmente a concretização incremental das metas e compartilhe os resultados para que medidas adequadas possam ser tomadas se os resultados estiverem em risco. 
  +  Fornecer os recursos necessários para realizar suas metas: analise regularmente se os recursos ainda são apropriados ou se recursos adicionais são necessários com base em novas informações, alterações nas metas, responsabilidades ou ambiente da empresa. 
  +  Defender suas equipes: mantenha o envolvimento com suas equipes para compreender a performance delas e se estão sendo afetadas por fatores externos. Quando suas equipes forem afetadas por fatores externos, reavalie metas e ajuste os objetivos conforme apropriado. Identifique os obstáculos que estão impedindo o progresso das suas equipes. Aja em nome das suas equipes para ajudar a resolver obstáculos e eliminar obrigações desnecessárias. 
  +  Motivar a adoção de práticas recomendadas: confirme as práticas recomendadas que oferecem benefícios quantificáveis e reconheça quem as cria e as adota. Incentive ainda mais a adoção para ampliar os benefícios obtidos. 
  +  Motivar a evolução de suas equipes: crie uma cultura de melhoria contínua. Incentive o crescimento e o desenvolvimento pessoal e organizacional. Forneça metas de longo prazo pelas quais se esforçar que exigirão conquistas incrementais ao longo do tempo. Ajuste essa visão para complementar necessidades, metas de negócios e ambiente de negócios à medida que eles mudarem. 

# OPS03-BP02 Os membros da equipe estão capacitados para executar ações quando os resultados estão em risco.
<a name="ops_org_culture_team_emp_take_action"></a>

 O proprietário da carga de trabalho definiu orientação e escopo, permitindo que os membros da equipe respondam quando os resultados estiverem em risco. Mecanismos de escalonamento são usados para obter orientação quando os eventos estão fora do escopo definido. 

 **Benefícios do estabelecimento desta prática recomendada:** Ao testar e validar alterações antecipadamente, você pode resolver problemas com custos reduzidos e limitar o impacto sobre seus clientes. Ao testar antes da implantação, você reduz a possibilidade de erros. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Os membros da equipe estão capacitados para executar ações quando os resultados estão em risco: forneça aos membros da equipe as permissões, as ferramentas e a oportunidade de praticar as habilidades necessárias para responderem com eficácia. 
  +  Fornecer aos membros da equipe a oportunidade de praticar as habilidades necessárias para responder: forneça ambientes alternativos e seguros em que os processos e os procedimentos possam ser testados e treinados com segurança. Realizar dias de jogos para permitir que os membros da equipe adquiram experiência para responder a incidentes reais em ambientes simulados e seguros. 
  +  Definir e confirmar a autoridade dos membros da equipe para executar ações: defina especificamente a autoridade dos membros da equipe para executar ações por meio da atribuição de permissões e acesso às workloads e aos componentes aos quais oferecem suporte. Reconheça que eles estão capacitados a executar ações quando os resultados estão em risco. 

# OPS03-BP03 Incentivo ao escalonamento
<a name="ops_org_culture_team_enc_escalation"></a>

 Os membros da equipe têm mecanismos e são incentivados a escalar as preocupações para os tomadores de decisão e as partes interessadas se acharem que os resultados estão em risco. O escalonamento deve ser realizado de maneira antecipada e frequente para que os riscos possam ser identificados e isso evite incidentes. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Incentivar o escalonamento antecipado e frequente: reconheça de forma organizacional que o escalonamento antecipado e frequente é a prática recomendada. Reconheça e aceite de maneira organizacional que os escalonamentos podem ser infundados e que é melhor ter a oportunidade de evitar um incidente do que perder essa oportunidade ao não escalonar. 
  +  Ter um mecanismo para o escalonamento: tenha procedimentos documentados que definem quando e como o escalonamento deve ocorrer. Documente a série de pessoas com autoridade crescente para tomar medidas ou aprovar ações e as informações de contato delas. O escalonamento deve continuar até que o membro da equipe esteja satisfeito por ter transmitido o risco a alguém capaz de lidar com ele ou tenha entrado em contato com a pessoa que detém o risco e a responsabilidade pela operação da workload. É essa pessoa que, em última análise, tem todas as decisões com relação à carga de trabalho. Os escalonamentos devem incluir a natureza do risco, a criticidade da carga de trabalho, quem é afetado, qual é o impacto e a urgência, ou seja, quando é o impacto esperado. 
  +  Proteger os funcionários que usam o escalonamento: tenha uma política que proteja os membros da equipe contra retaliações se fizerem um escalonamento em relação a um tomador de decisão ou parte interessada não responsivo. Tenha mecanismos implementados para identificar se isso está ocorrendo e responder de maneira adequada. 

# OPS03-BP04 Comunicações oportunas, claras e acionáveis
<a name="ops_org_culture_effective_comms"></a>

 Mecanismos existem e são usados para fornecer avisos oportunos aos membros da equipe acerca de riscos conhecidos e eventos planejados. Contexto, detalhes e tempo necessários (quando possível) são fornecidos para ajudar a determinar se há necessidade de uma ação e qual ação é necessária e a tomar as medidas necessárias em tempo hábil. Por exemplo, a notificação de vulnerabilidades de software para que a aplicação de patches possa ser expressa ou o aviso de promoções de vendas planejadas para que um congelamento de alterações possa ser implementado para evitar o risco de interrupção do serviço. Eventos planejados podem ser registrados em um calendário de alterações ou programação de manutenção para que os membros da equipe possam identificar quais atividades estão pendentes. 

 **Resultado desejado:** 
+  A comunicação fornece contexto, detalhes e expectativas de tempo. 
+  Os membros da equipe têm um entendimento claro sobre quando e como agir em resposta a comunicações. 
+  Utilize calendários de alterações para chamar a atenção para as alterações previstas. 

 **Antipadrões comuns:** 
+  Um alerta falso-positivo é acionado várias vezes por semana. Você silencia a notificação toda vez em que ela ocorre. 
+  Você recebe uma solicitação para alterar seu grupo de segurança, mas não é passada nenhuma expectativa sobre quando isso deve ocorrer. 
+  Você recebe notificações constantes por chat quando a escala dos sistemas é aumentada verticalmente, mas nenhuma ação é necessária. Você evita o canal por chat e perde uma notificação importante. 
+  Fizeram uma alteração na produção sem informar a equipe de operações. A alteração aciona um alerta e a equipe de plantão é ativada. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Sua organização evita a fadiga de alertas. 
+  Os membros da equipe podem agir com o contexto necessário e as expectativas indispensáveis. 
+  As alterações podem ser feitas durante períodos apropriados e reduzir o risco. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Para implementar esta prática recomendada, você precisa trabalhar com as partes interessadas na organização para ajustar padrões de comunicação. Divulgue esses padrões para toda a organização. Identifique e remova alertas falso-positivos ou que fiquem sempre ativos. Utilize calendários de alterações para que os membros da equipe saibam quando é possível agir e quais atividades estão pendentes. Verifique se as comunicações geram ações claras com o contexto necessário. 

 **Exemplo de clientes** 

 A Loja UmaEmpresa usa o chat como principal meio de comunicação. Alertas e outras informações são divulgados em canais específicos. Quando alguém precisa agir, o resultado desejado é claramente expresso, e, em muitos casos, as pessoas recebem um runbook ou manual para uso nessas situações. O calendário de alterações é usado para programar alterações importantes nos sistemas de produção. 

 **Etapas da implementação** 

1.  Analise os alertas para identificar falso-positivos ou alertas que são acionados constantemente. Remova ou altere esses alertas para que sejam acionados quando há necessidade de intervenção humana. Se um alerta for acionado, forneça um runbook ou manual. 

   1.  Você pode usar [Documentos do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html) para criar manuais e runbooks para alertas. 

1.  Mecanismos estão em vigor para fornecer notificações de riscos ou eventos planejados de maneira clara e prática com aviso prévio em tempo suficiente para permitir respostas apropriadas. Use listas de e-mails ou canais por chat para enviar notificações antes dos eventos planejados. 

   1.  [É possível usar o Amazon Q Developer in chat applications](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) para enviar alertas e responder a eventos dentro da plataforma de mensagens de suas organizações. 

1.  Forneça uma fonte de informações acessível em que eventos planejados possam ser descobertos. Forneça notificações de eventos planejados oriundos do mesmo sistema. 

   1.  [O Calendário de Alterações do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) pode ser usado para criar períodos em que as alterações podem ocorrer. Isso oferece aos membros da equipe um aviso prévio sobre quando eles podem fazer alterações com segurança. 

1.  Monitore notificações de vulnerabilidade e informações de patches para identificar vulnerabilidades nos riscos reais e potenciais associados aos componentes da workload. Forneça uma notificação aos membros da equipe para que eles possam agir. 

   1.  Você pode assinar os [boletins de segurança da AWS](https://aws.amazon.com/security/security-bulletins/) para receber notificações sobre vulnerabilidades na AWS. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS07-BP03 Usar runbooks para realizar procedimentos](ops_ready_to_support_use_runbooks.md): para que as comunicações tenham efeito prático, forneça um runbook quando o resultado for conhecido. 
+  [OPS07-BP04 Usar manuais para investigar problemas](ops_ready_to_support_use_playbooks.md): quando não se conhece o resultado, os manuais podem tornar as comunicações acionáveis. 

 **Documentos relacionados:** 
+ [Boletins de segurança da AWS](https://aws.amazon.com/security/security-bulletins)
+ [ Open CVE ](https://www.opencve.io/welcome)

 **Exemplos relacionados:** 
+ [ Laboratórios do Well-Architected: Gerenciamento de inventário e patches (Nível 100) ](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)

 **Serviços relacionados:** 
+ [Amazon Q Developer in chat applications](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html)
+ [Calendário de alterações do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html)
+ [Documentos do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)

# OPS03-BP05 Incentivo à experimentação
<a name="ops_org_culture_team_enc_experiment"></a>

A experimentação é um catalisador para transformar novas ideias em produtos e recursos. Ela acelera o aprendizado e mantém os membros da equipe interessados e envolvidos. Os membros da equipe são incentivados a experimentar com frequência para promover a inovação. Mesmo quando um resultado não desejado ocorre, é importante saber o que não se deve fazer. Os membros da equipe não são punidos por experimentos bem-sucedidos com resultados indesejados. 

 **Resultado desejado:** 
+  Sua organização incentiva a experimentação para promover a inovação. 
+  Os experimentos são usados como oportunidade de aprendizado. 

 **Antipadrões comuns:** 
+  Você deseja executar um teste A/B, mas não há nenhum mecanismo para conduzir o experimento. Você implanta uma alteração de interface do usuário sem a possibilidade de testá-la. O resultado é uma experiência negativa para o cliente. 
+  Sua empresa tem apenas o ambiente de preparação e produção. Como não há área restrita para testes para experimentar novos recursos ou produtos, você precisa realizar experimentos no ambiente de produção. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  A experimentação promove a inovação. 
+  Você reagir mais depressa ao feedback dos usuários por meio da experimentação. 
+  Sua organização desenvolve uma cultura de aprendizado. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Os experimentos devem ser conduzidos de maneira segura. Utilize vários ambientes para experimentar, sem colocar em risco os recursos da produção. Use testes A/B e sinalizadores de recursos para testar experimentos. Ofereça aos membros da equipe a possibilidade de conduzir experimentos em um ambiente de área restrita para testes. 

 **Exemplo de clientes** 

 A Loja UmaEmpresa estimula a experimentação. Os membros da equipe podem usar 20% da semana de trabalho para experimentar ou aprender novas tecnologias. Eles têm um ambiente de área restrita para testes no qual podem inovar. São usados testes A/B para novos recursos com o objetivo de validá-los com um feedback de usuário real. 

 **Etapas da implementação** 

1.  Trabalhe com a liderança em toda a sua organização para favorecer a experimentação. Os membros da equipe devem ser incentivados a conduzir experimentos de maneira segura. 

1.  Ofereça aos membros da equipe um ambiente em que eles possa experimentar com segurança. Eles devem ter acesso a um ambiente semelhante ao de produção. 

   1.  Você pode usar uma Conta da AWS separada para criar um ambiente de área restrita para testes para experimentação. O [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) pode ser usado para provisionar essas contas. 

1.  Use sinalizadores de recursos e testes A/B para experimentar com segurança e coletar feedback dos usuários. 

   1.  O [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) Feature Flags oferece a possibilidade de criar sinalizadores de recursos. 

   1.  O [Amazon CloudWatch Evidently](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html) pode ser usado para realizar testes A/B em uma implantação limitada. 

   1.  Você pode usar [versões do AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) para implantar uma nova versão de uma função para testes beta. 

 **Nível de esforço do plano de implementação:** alto. A viabilização de um ambiente para experimentação e de uma maneira segura para os membros da equipe conduzirem experimentos pode exigir um investimento significativo. Você também pode precisar modificar o código da aplicação para usar sinalizadores de recursos ou respaldar testes A/B. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS11-BP02 Executar análise pós-incidente](ops_evolve_ops_perform_rca_process.md): aprender com incidentes é um motivador fundamental para a inovação, bem como a experimentação. 
+  [OPS11-BP03 Implementar loops de feedback](ops_evolve_ops_feedback_loops.md): os ciclos de feedback são um componente importante da experimentação. 

 **Documentos relacionados:** 
+ [ Uma visão interna da cultura da Amazon: experimentação, erro e obsessão pelo cliente ](https://aws.amazon.com/blogs/industries/an-inside-look-at-the-amazon-culture-experimentation-failure-and-customer-obsession/)
+ [ Práticas recomendadas para criar e gerenciar contas em área restrita para testes na AWS](https://aws.amazon.com/blogs/mt/best-practices-creating-managing-sandbox-accounts-aws/)
+ [ Crie uma cultura de experimentação viabilizada pela nuvem ](https://aws.amazon.com/blogs/enterprise-strategy/create-a-culture-of-experimentation-enabled-by-the-cloud/)
+ [ Viabilização da experimentação e inovação na nuvem na SulAmérica Seguros ](https://aws.amazon.com/blogs/mt/enabling-experimentation-and-innovation-in-the-cloud-at-sulamerica-seguros/)
+ [ Experimente mais, erre menos ](https://aws.amazon.com/blogs/enterprise-strategy/experiment-more-fail-less/)
+ [ Organização do ambiente da AWS usando várias contas: UO de área restrita para testes ](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/sandbox-ou.html)
+ [ Como usar o AWS AppConfig Feature Flags ](https://aws.amazon.com/blogs/mt/using-aws-appconfig-feature-flags/)

 **Vídeos relacionados:** 
+ [AWS On Air ft. Amazon CloudWatch Evidently \$1 AWS Eventos ](https://www.youtube.com/watch?v=ydX7lRNKAOo)
+ [AWS On Air San Fran Summit 2022 ft. Integração do AWS AppConfig Feature Flags com o Jira ](https://www.youtube.com/watch?v=miAkZPtjqHg)
+ [AWS re:Invent 2022: Implantação não é lançamento: controle seus lançamentos com sinalizadores de recursos (BOA305-R) ](https://www.youtube.com/watch?v=uouw9QxVrE8)
+ [ Crie programaticamente uma Conta da AWS com o AWS Control Tower](https://www.youtube.com/watch?v=LxxQTPdSFgw)
+ [ Configuração de um ambiente de várias contas da AWS que usa as práticas recomendadas para AWS Organizations](https://www.youtube.com/watch?v=uOrq8ZUuaAQ)

 **Exemplos relacionados:** 
+ [AWS Innovation Sandbox ](https://aws.amazon.com/solutions/implementations/aws-innovation-sandbox/)
+ [ Personalização básica de ponta a ponta para comércio eletrônico ](https://catalog.workshops.aws/personalize-101-ecommerce/en-US/labs/ab-testing)

 **Serviços relacionados:** 
+  [Amazon CloudWatch Evidently](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html) 
+  [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 

# OPS03-BP06 Os membros da equipe estão capacitados e são incentivados a manter e a aumentar seus conjuntos de habilidades.
<a name="ops_org_culture_team_enc_learn"></a>

 As equipes devem aumentar os conjuntos de habilidades para adotar novas tecnologias e apoiar mudanças na demanda e responsabilidades no apoio às suas cargas de trabalho. O desenvolvimento das habilidades em novas tecnologias costuma ser uma fonte de satisfação dos membros da equipe e apoia a inovação. Ofereça apoio aos membros da equipe na busca e atualização de certificações do setor que validem e reconheçam as suas habilidades crescentes. Treine profissionais em diferentes funções para promover a transferência de conhecimento e reduzir o risco de impacto significativo quando você perde membros da equipe qualificados e experientes com conhecimento institucional. Reserve tempo estruturado e dedicado para o aprendizado. 

 A AWS fornece recursos, incluindo o [Centro de recursos de conceitos básicos da AWS](https://aws.amazon.com/getting-started/), [Blogs da AWS](https://aws.amazon.com/blogs/), [AWS Online Tech Talks](https://aws.amazon.com/getting-started/), [Eventos e webinars da AWS](https://aws.amazon.com/events/)e os [Laboratórios do AWS Well-Architected](https://wellarchitectedlabs.com/), que fornecem orientações, exemplos e demonstrações detalhadas para educar suas equipes. 

 A AWS também compartilha as práticas recomendadas e os padrões que aprendemos durante a operação da AWS na [Amazon Builders’ Library](https://aws.amazon.com/builders-library/) e uma grande variedade de outros materiais educacionais úteis por meio do [Blog da AWS](https://aws.amazon.com/blogs/) e [O podcast oficial da AWS](https://aws.amazon.com/podcasts/aws-podcast/). 

 Você deve aproveitar os recursos educacionais fornecidos pela AWS, como os laboratórios do AWS Well-Architected, [AWS Support](https://aws.amazon.com/premiumsupport/programs/) ([Centro de Conhecimentos da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/), [Fóruns de discussão da AWS](https://forums.aws.amazon.com/index.jspa)e aos [AWS Support Center](https://console.aws.amazon.com/support/home/)) e [Documentação da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) para instruir suas equipes. Entre em contato com o AWS Support por meio do AWS Support Center para obter ajuda com relação às suas dúvidas sobre a AWS. 

 [Treinamento da AWS and Certification](https://aws.amazon.com/training/) fornece alguns treinamentos gratuitos por meio de cursos digitais autoguiados sobre os conceitos básicos da AWS. Também é possível inscrever-se em treinamento administrado por instrutor para oferecer suporte adicional ao desenvolvimento das habilidades em AWS de suas equipes. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Os membros da equipe estão capacitados e são incentivados a manter e a ampliar seus conjuntos de habilidades: para adotar novas tecnologias e oferecer suporte às mudanças na demanda e nas responsabilidades de suporte às workloads, é necessário treinamento contínuo. 
  +  Fornecer recursos para treinamento: forneça tempo estruturado dedicado, acesso ao material de treinamento, recursos de laboratório e suporte à participação em conferências e organizações profissionais que fornecem oportunidades para aprendizado para instrutores e colegas. Forneça aos membros da equipe júnior acesso aos membros da equipe sênior como mentores ou permita que eles sigam o trabalho deles e sejam expostos aos métodos e às habilidades que têm. Incentive o aprendizado sobre conteúdo não diretamente relacionado ao trabalho para ter uma perspectiva mais ampla. 
  +  Treinamento da equipe e envolvimento entre equipes: planeje as necessidades de treinamento contínuo dos membros da equipe. Ofereça oportunidades para que os membros da equipe se juntem a outras equipes (temporária ou permanentemente) para compartilhar habilidades e melhores práticas que beneficiam toda a organização 
  +  Oferecer suporte à busca e à manutenção de certificações do setor: ofereça suporte à aquisição e manutenção de certificações do setor que validam o aprendizado e reconheça as conquistas dos membros da equipe. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Centro de recursos de conceitos básicos da AWS](https://aws.amazon.com/getting-started/) 
+  [Blogs da AWS](https://aws.amazon.com/blogs/) 
+  [Conformidade da Nuvem AWS](https://aws.amazon.com/compliance/) 
+  [Fóruns de discussão da AWS](https://forums.aws.amazon.com/index.jspa) 
+  [Documentação da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+  [AWS Online Tech Talks](https://aws.amazon.com/getting-started/) 
+  [Eventos e webinars da AWS](https://aws.amazon.com/events/) 
+  [Centro de Conhecimentos da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [AWS Support](https://aws.amazon.com/premiumsupport/programs/) 
+  [Treinamento da AWS and Certification](https://aws.amazon.com/training/) 
+  [Laboratórios do AWS Well-Architected](https://wellarchitectedlabs.com/), 
+  [Amazon Builders’ Library](https://aws.amazon.com/builders-library/) 
+  [O podcast oficial da AWS](https://aws.amazon.com/podcasts/aws-podcast/). 

# OPS03-BP07 Fornecer recursos adequados às equipes
<a name="ops_org_culture_team_res_appro"></a>

 Mantenha a capacidade dos membros da equipe e forneça ferramentas e recursos para dar suporte às necessidades da workload. A sobrecarga de membros da equipe aumenta o risco de incidentes resultantes de erros humanos. Os investimentos em ferramentas e em recursos (por exemplo, o fornecimento de automação para atividades executadas com frequência) podem escalar a eficácia da equipe, permitindo que ela ofereça suporte a atividades adicionais. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Fornecer recursos adequados às equipes: compreenda o sucesso das equipes e os fatores que contribuem para o sucesso ou para o insucesso. Aja para apoiar equipes com os recursos apropriados. 
  +  Compreender a performance da equipe: meça a aquisição de resultados operacionais e o desenvolvimento de ativos realizados pela equipe. Acompanhe as alterações na saída e na taxa de erros ao longo do tempo. Envolva-se com as equipes para compreender os desafios relacionados ao trabalho que as afetam (por exemplo, aumento de responsabilidades, mudanças na tecnologia, perda de pessoal ou aumento de clientes atendidos pelo suporte). 
  +  Compreender os impactos na performance das equipes: mantenha-se engajado com as equipes para entender como elas estão desempenhando e se há fatores externos que as afetam. Quando suas equipes forem afetadas por fatores externos, reavalie metas e ajuste os objetivos conforme apropriado. Identifique os obstáculos que estão impedindo o progresso das suas equipes. Aja em nome das suas equipes para ajudar a resolver obstáculos e eliminar obrigações desnecessárias. 
  +  Fornecer os recursos necessários para as equipes serem bem-sucedidas: analise regularmente se os recursos ainda são adequados, ou se são necessários recursos adicionais, e faça os ajustes apropriados para oferecer suporte às equipes. 

# OPS03-BP08 Opiniões diversas são incentivadas e procuradas dentro e entre equipes
<a name="ops_org_culture_diverse_inc_access"></a>

 Aproveite a diversidade entre organizações para buscar várias perspectivas únicas. Use essa abordagem para aumentar a inovação, desafiar suas suposições e reduzir o risco de viés de confirmação. Aumente a inclusão, a diversidade e a acessibilidade em suas equipes para obter perspectivas benéficas. 

 A cultura organizacional tem impacto direto na satisfação com a tarefa e na retenção dos membros da equipe. Incentive o envolvimento e as habilidades dos membros da equipe para promover o êxito da sua empresa. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Buscar opiniões e perspectivas diversas: incentive contribuições de todos. Ouça os grupos de pequena representação. Alterne as funções e as responsabilidades em reuniões. 
  +  Expandir funções e responsabilidades: ofereça oportunidade para que os membros da equipe assumam funções que não poderiam assumir de outra forma. Eles ganharão experiência e perspectiva com a função e com as interações com novos membros da equipe com os quais não interagiriam de outra forma. Eles levarão a experiência e perspectiva deles para a nova função e para os membros da equipe com os quais interagirem. Conforme aumenta a perspectiva, mais oportunidades de negócios podem surgir ou novas oportunidades de melhoria podem ser identificadas. Faça com que os membros de uma equipe se revezem em tarefas comuns que outras pessoas normalmente executam para compreender as demandas e o impacto de realizá-las. 
  +  Fornecer um ambiente seguro e acolhedor: implante políticas e controles que protejam a segurança física e mental dos membros da equipe na organização. Os membros da equipe devem poder interagir sem medo de represálias. Quando os membros da equipe se sentem seguros e bem-vindos, eles provavelmente estão envolvidos e são produtivos. Quanto mais diversificada sua organização, melhor será o entendimento das pessoas que você apoia, incluindo seus clientes. Quando os membros da equipe estiverem confortáveis, sentirem-se à vontade para falar e confiarem que serão ouvidos, será mais provável que eles dividam ideias valiosas (por exemplo, oportunidades de marketing, necessidades de acessibilidade, segmentos de mercado não atendidos, riscos não reconhecidos no seu ambiente). 
  +  Permitir que os membros da equipe participem plenamente: forneça os recursos necessários para que os funcionários participem totalmente de todas as atividades relacionadas ao trabalho. Os membros da equipe que enfrentam desafios diários desenvolveram habilidades para contornar esses desafios. Essas habilidades desenvolvidas exclusivamente podem oferecer benefícios significativos para a sua organização. O apoio aos membros da equipe com as acomodações necessárias aumentará os benefícios que você poderá receber das contribuições deles. 

# Preparar
<a name="a-prepare"></a>

**Topics**
+ [OPERAÇÕES 4. Como implementar a observabilidade em sua workload?](ops-04.md)
+ [OPERAÇÕES 5. Como reduzir defeitos, facilitar a correção e melhorar o fluxo na produção?](ops-05.md)
+ [OPERAÇÕES 6. Como reduzir os riscos de implantação?](ops-06.md)
+ [OPERAÇÕES 7. Como saber se está pronto para oferecer suporte a uma workload?](ops-07.md)

# OPERAÇÕES 4. Como implementar a observabilidade em sua workload?
<a name="ops-04"></a>

Implemente a observabilidade na workload para que você possa entender seu estado e tomar decisões baseadas em dados com base nos requisitos de negócios.

**Topics**
+ [OPS04-BP01 Identificar os indicadores-chave de performance](ops_observability_identify_kpis.md)
+ [OPS04-BP02 Implementar a telemetria de aplicações](ops_observability_application_telemetry.md)
+ [OPS04-BP03 Implementar a telemetria da experiência do usuário](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 Implementar a telemetria de dependências](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 Implementar rastreamento distribuído](ops_observability_dist_trace.md)

# OPS04-BP01 Identificar os indicadores-chave de performance
<a name="ops_observability_identify_kpis"></a>

 A implementação da observabilidade em sua workload começa com a compreensão de seu estado e a tomada de decisões baseadas em dados conforme os requisitos de negócios. Uma das formas mais eficazes de garantir o alinhamento entre as atividades de monitoramento e os objetivos de negócios é definir e monitorar os indicadores-chave de performance (KPIs). 

 **Resultado desejado:** Práticas de observabilidade eficientes que estão estreitamente alinhadas aos objetivos de negócios, garantindo que os esforços de monitoramento estejam sempre a serviço de resultados comerciais tangíveis. 

 **Antipadrões comuns:** 
+  KPIs indefinidos: trabalhar sem KPIs claros pode levar ao monitoramento excessivo ou insuficiente, perdendo sinais vitais. 
+  KPIs estáticos: não revisitar ou refinar os KPIs à medida que a workload ou os objetivos de negócios evoluem. 
+  Desalinhamento: foco em métricas técnicas que não se correlacionam diretamente com os resultados comerciais ou são mais difíceis de correlacionar com problemas do mundo real. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Facilidade de identificação de problemas: os KPIs de negócios geralmente mostram os problemas com mais clareza do que as métricas técnicas. Uma queda em um KPI comercial pode identificar um problema com mais eficiência do que analisar várias métricas técnicas. 
+  Alinhamento comercial: garante que as atividades de monitoramento apoiem diretamente os objetivos de negócios. 
+  Eficiência: priorize os recursos de monitoramento e a atenção nas métricas que importam. 
+  Proatividade: reconheça e resolva os problemas antes que eles tenham implicações comerciais mais amplas. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Para definir com eficácia os KPIs da workload: 

1.  **Comece com os resultados comerciais:** Antes de mergulhar nas métricas, entenda o resultado comercial desejado. É aumento de vendas, maior engajamento do usuário ou tempos de resposta mais rápidos? 

1.  **Correlacione métricas técnicas com objetivos de negócios:** Nem todas as métricas técnicas têm um impacto direto nos resultados comerciais. Identifique aquelas que têm, mas geralmente é mais fácil identificar um problema usando um KPI comercial. 

1.  **Use o [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html):** Empregue o CloudWatch para definir e monitorar métricas que representam seus KPIs. 

1.  **Revise e atualize regularmente os KPIs:** À medida que sua workload e seus negócios evoluem, mantenha seus KPIs relevantes. 

1.  **Envolva as partes interessadas:** Envolva as equipes técnicas e comerciais na definição e revisão dos KPIs. 

 **Nível de esforço do plano de implementação:** médio 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [OPS04-BP02 Implementar a telemetria de aplicações](ops_observability_application_telemetry.md)
+ [OPS04-BP03 Implementar a telemetria da experiência do usuário](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 Implementar a telemetria de dependências](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 Implementar rastreamento distribuído](ops_observability_dist_trace.md)

 **Documentos relacionados:** 
+ [AWS Observability Best Practices (Práticas recomendadas de observabilidade da AWS ) ](https://aws-observability.github.io/observability-best-practices/)
+ [ Guia do usuário do CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS Observability Skill Builder Course (Curso de desenvolvimento de habilidades de observabilidade da AWS) ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)

 **Vídeos relacionados:** 
+ [ Developing an observability strategy (Desenvolvimento de uma estratégia de observabilidade) ](https://www.youtube.com/watch?v=Ub3ATriFapQ)

 **Exemplos relacionados:** 
+  [Um workshop de observabilidade](https://catalog.workshops.aws/observability/en-US) 

# OPS04-BP02 Implementar a telemetria de aplicações
<a name="ops_observability_application_telemetry"></a>

 A telemetria de aplicações serve como base para a observabilidade da workload. É fundamental emitir uma telemetria que ofereça informações práticas sobre o estado de sua aplicação e a obtenção de resultados técnicos e comerciais. Da solução de problemas à medição do impacto de um novo recurso ou à garantia do alinhamento com os indicadores-chave de performance (KPIs) de negócios, a telemetria de aplicações informa a maneira como você cria, opera e desenvolve sua workload. 

 Métricas, logs e rastreamentos formam os três pilares principais da observabilidade. Eles servem como ferramentas de diagnóstico que descrevem o estado de sua aplicação. Com o tempo, eles auxiliam na criação de linhas de base e na identificação de anomalias. No entanto, para garantir o alinhamento entre as atividades de monitoramento e os objetivos de negócios, é fundamental definir e monitorar os KPIs. Os KPIs de negócios geralmente facilitam a identificação de problemas em comparação com métricas técnicas isoladas. 

 Outros tipos de telemetria, como monitoramento de usuários reais (RUM) e transações sintéticas, complementam essas fontes de dados primárias. O RUM oferece informações sobre as interações do usuário em tempo real, enquanto as transações sintéticas simulam possíveis comportamentos do usuário, ajudando a detectar gargalos antes que usuários reais os encontrem. 

 **Resultado desejado:** Obtenha insights acionáveis sobre o desempenho de sua workload. Esses insights permitem que você tome decisões proativas sobre otimização de desempenho, obtenha maior estabilidade da workload, simplifique os processos de CI/CD e utilize recursos de forma eficaz. 

 **Antipadrões comuns:** 
+  Observabilidade incompleta: negligência da incorporação da observabilidade em todas as camadas da workload, resultando em pontos cegos que podem obscurecer insights vitais sobre desempenho e comportamento do sistema. 
+  Visualização fragmentada dos dados: quando os dados estão espalhados por várias ferramentas e sistemas, torna-se difícil manter uma visão holística da integridade e do desempenho de sua workload. 
+  Problemas relatados pelo usuário: um sinal de que falta a detecção proativa de problemas por meio da telemetria e do monitoramento de KPI de negócios. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Tomada de decisão informada: com insights de telemetria e KPIs de negócios, você pode tomar decisões baseadas em dados. 
+  Eficiência operacional aprimorada: a utilização de recursos baseada em dados leva à economia de custos. 
+  Estabilidade aprimorada da workload: detecção e resolução de problemas mais rápidas, levando a um melhor tempo de atividade. 
+  Processos simplificados de CI/CD: os insights dos dados de telemetria facilitam o refinamento dos processos e a entrega confiável do código. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Para implementar a telemetria de aplicações para sua workload, use serviços da AWS, como o [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) e o [AWS X-Ray](https://aws.amazon.com/xray/). O Amazon CloudWatch fornece um conjunto abrangente de ferramentas de monitoramento, permitindo que você observe seus recursos e aplicações em ambientes da AWS e on-premises. Ele coleta, rastreia e analisa métricas, consolida e monitora dados de log e responde às mudanças em seus recursos, aprimorando sua compreensão de como a workload opera. Em conjunto, o AWS X-Ray permite rastrear, analisar e depurar suas aplicações, oferecendo uma compreensão profunda do comportamento da sua workload. Com recursos como mapas de serviços, distribuições de latência e cronogramas de rastreamento, o X-Ray fornece informações sobre o desempenho da workload e os gargalos que a afetam. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  **Identifique quais dados coletar:** Garanta as métricas, os logs e os rastreamentos essenciais que ofereceriam informações substanciais sobre a integridade, o desempenho e o comportamento de sua workload. 

1.  **Implemente o agente do [CloudWatch](https://aws.amazon.com/cloudwatch/) :** O agente do CloudWatch é fundamental na aquisição de métricas do sistema e da aplicação e de logs de sua workload e de sua infraestrutura subjacente. O agente do CloudWatch também pode ser usado para coletar OpenTelemetry ou rastreamentos do X-Ray e enviá-los para o X-Ray. 

1.  **Defina e monitore os KPIs de negócios:** Estabeleça [métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) que se alinham com os seus [resultados empresariais](https://aws-observability.github.io/observability-best-practices/guides/operational/business/monitoring-for-business-outcomes/). 

1.  **Instrumente sua aplicação com o AWS X-Ray:** além de implantar o agente do CloudWatch, é fundamental [instrumentar sua aplicação](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html) para emitir dados de rastreamento. Esse processo pode fornecer mais informações sobre o comportamento e o desempenho da sua workload. 

1.  **Padronize a coleta de dados em sua aplicação:** Padronize as práticas de coleta de dados em toda a sua aplicação. A uniformidade ajuda a correlacionar e analisar dados, fornecendo uma visão abrangente do comportamento de sua aplicação. 

1.  **Analise e aja com base nos dados:** Depois que a coleta e a normalização de dados estiverem em vigor, use o [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) para análise de métricas e logs e o [AWS X-Ray](https://aws.amazon.com/xray/features/) para análise de rastreamentos. Essa análise pode gerar informações cruciais sobre a integridade, o desempenho e o comportamento de sua workload, orientando o processo de tomada de decisão. 

 **Nível de esforço do plano de implementação:** Alto 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS04-BP01 Identificar os indicadores-chave de performance](ops_observability_identify_kpis.md) 
+  [OPS04-BP03 Implementar a telemetria da experiência do usuário](ops_observability_customer_telemetry.md) 
+  [OPS04-BP04 Implementar a telemetria de dependências](ops_observability_dependency_telemetry.md) 
+  [OPS04-BP05 Implementar rastreamento distribuído](ops_observability_dist_trace.md) 

 **Documentos relacionados:** 
+ [AWS Observability Best Practices (Práticas recomendadas de observabilidade da AWS ) ](https://aws-observability.github.io/observability-best-practices/)
+ [ Guia do usuário do CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ Guia do desenvolvedor do AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Instrumentação de sistemas distribuídos para visibilidade operacional ](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility)
+ [AWS Observability Skill Builder Course (Curso de desenvolvimento de habilidades de observabilidade da AWS) ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
+ [ Quais são as novidades do Amazon CloudWatch? ](https://aws.amazon.com/about-aws/whats-new/management-and-governance/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23amazon-cloudwatch)
+ [ Quais são as novidades do AWS X-Ray? ](https://aws.amazon.com/about-aws/whats-new/developer-tools/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23aws-x-ray)

 **Vídeos relacionados:** 
+ [AWS re:Invent 2022 - Observability best practices at Amazon (AWS re:Invent 2022: práticas recomendadas de observabilidade na Amazon) ](https://youtu.be/zZPzXEBW4P8)
+ [AWS re:Invent 2022 - Developing an observability strategy (AWS re:Invent 2022: desenvolvimento de uma estratégia de observabilidade) ](https://youtu.be/Ub3ATriFapQ)

 **Exemplos relacionados:** 
+  [Um workshop de observabilidade](https://catalog.workshops.aws/observability/en-US) 
+ [ Biblioteca de soluções da AWS: monitoramento de aplicações com Amazon CloudWatch ](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch)

# OPS04-BP03 Implementar a telemetria da experiência do usuário
<a name="ops_observability_customer_telemetry"></a>

 É essencial obter insights profundos sobre as experiências dos clientes e as interações com sua aplicação. O monitoramento de usuários reais (RUM) e as transações sintéticas servem como ferramentas poderosas para essa finalidade. O RUM fornece dados sobre interações reais do usuário, oferecendo uma perspectiva não filtrada da satisfação do usuário, enquanto as transações sintéticas simulam as interações do usuário, ajudando a detectar possíveis problemas antes mesmo que eles afetem os usuários reais. 

 **Resultado desejado:** Uma visão holística da experiência do cliente, detecção proativa de problemas e otimização das interações do usuário para oferecer experiências digitais perfeitas. 

 **Antipadrões comuns:** 
+  Aplicações sem monitoramento de usuários reais (RUM): 
  +  Detecção atrasada de problemas: sem o RUM, talvez você não fique ciente dos gargalos ou problemas de desempenho até que os usuários reclamem. Essa abordagem reativa pode levar à insatisfação do cliente. 
  +  Falta de insights sobre a experiência do usuário: não usar o RUM significa perder dados cruciais que mostram como usuários reais interagem com sua aplicação, limitando sua capacidade de otimizar a experiência do usuário. 
+  Aplicações sem transações sintéticas: 
  +  Casos extremos perdidos: transações sintéticas ajudam você a testar caminhos e funções que podem não ser usados com frequência por usuários comuns, mas são essenciais para determinadas funções de negócios. Sem eles, esses caminhos podem ter problemas de funcionamento e passar despercebidos. 
  +  Verificação de problemas quando a aplicação não está sendo usada: testes sintéticos regulares podem simular momentos em que usuários reais não estão interagindo ativamente com sua aplicação, garantindo que o sistema sempre funcione corretamente. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Detecção proativa de problemas: identifique e resolva possíveis problemas antes que eles afetem usuários reais. 
+  Experiência otimizada do usuário: o feedback contínuo do RUM ajuda a refinar e aprimorar a experiência geral do usuário. 
+  Informações sobre o desempenho do dispositivo e do navegador: entenda o desempenho da sua aplicação em vários dispositivos e navegadores, permitindo uma maior otimização. 
+  Fluxos de trabalho de negócios validados: transações sintéticas regulares garantem que as principais funcionalidades e os caminhos críticos permaneçam operacionais e eficientes. 
+  Desempenho aprimorado da aplicação: utilize as informações coletadas de dados reais do usuário para melhorar a capacidade de resposta e a confiabilidade da aplicação. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Para aproveitar o RUM e as transações sintéticas para a telemetria da atividade do usuário, a AWS oferece serviços como [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) e [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html). Métricas, logs e rastreamentos, juntamente com dados de atividades do usuário, fornecem uma visão abrangente do estado operacional da aplicação e da experiência do usuário. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  **Implemente o Amazon CloudWatch RUM:** integre sua aplicação ao CloudWatch RUM para coletar, analisar e apresentar dados reais do usuário. 

   1.  Use a [biblioteca em JavaScript do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) para integrar o RUM à sua aplicação. 

   1.  Configure painéis para visualizar e monitorar dados reais do usuário. 

1.  **Configuração do CloudWatch Synthetics:** crie canários ou rotinas com script que simulem as interações do usuário com sua aplicação. 

   1.  Defina fluxos de trabalho e caminhos de aplicação críticos. 

   1.  Projete canários usando [scripts do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) para simular as interações do usuário nesses caminhos. 

   1.  Programe e monitore os canários para serem executados em intervalos específicos, garantindo verificações de desempenho consistentes. 

1.  **Analise e aja com base nos dados:** Utilize dados de RUM e transações sintéticas para obter insights e tomar medidas corretivas quando anomalias forem detectadas. Use painéis do CloudWatch e alarmes para se manter informado. 

 **Nível de esforço do plano de implementação:** médio 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS04-BP01 Identificar os indicadores-chave de performance](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementar a telemetria de aplicações](ops_observability_application_telemetry.md) 
+  [OPS04-BP04 Implementar a telemetria de dependências](ops_observability_dependency_telemetry.md) 
+  [OPS04-BP05 Implementar rastreamento distribuído](ops_observability_dist_trace.md) 

 **Documentos relacionados:** 
+ [ Guia do Amazon CloudWatch RUM ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [ Guia do Amazon CloudWatch Synthetics ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)

 **Vídeos relacionados:** 
+ [ Optimize applications through end user insights with Amazon CloudWatch RUM (Otimização de aplicações por meio de insights sobre o usuário final com o Amazon CloudWatch RUM) ](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [AWS on Air ft. Real-User Monitoring for Amazon CloudWatch (Monitoramento de usuários reais do Amazon CloudWatch) ](https://www.youtube.com/watch?v=r6wFtozsiVE)

 **Exemplos relacionados:** 
+ [ Um workshop de observabilidade ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Repositório Git do Amazon CloudWatch RUM Web Client ](https://github.com/aws-observability/aws-rum-web)
+ [ Uso do Amazon CloudWatch Synthetics para medir o tempo de carregamento da página ](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance)

# OPS04-BP04 Implementar a telemetria de dependências
<a name="ops_observability_dependency_telemetry"></a>

 A telemetria de dependências é essencial para monitorar a integridade e a performance dos serviços e componentes externos dos quais a workload depende. Ela fornece informações valiosas sobre acessibilidade, tempos limite e outros eventos críticos relacionados a dependências, como DNS, bancos de dados ou APIs de terceiros. Ao instrumentar sua aplicação para emitir métricas, logs e rastreamentos sobre essas dependências, você obtém uma compreensão mais clara dos possíveis gargalos, problemas de performance ou falhas que podem afetar a workload. 

 **Resultado desejado:** As dependências das quais a workload depende estão funcionando conforme o esperado, permitindo que você resolva problemas de forma proativa e garanta a performance ideal da workload. 

 **Antipadrões comuns:** 
+  Negligenciar as dependências externas: focar apenas nas métricas internas da aplicação e negligenciar as métricas relacionadas às dependências externas. 
+  Falta de monitoramento proativo: aguardar o surgimento de problemas em vez de monitorar continuamente a integridade e a performance da dependência. 
+  Monitoramento em silos: usar várias ferramentas de monitoramento diferentes, o que pode resultar em visualizações fragmentadas e inconsistentes da integridade da dependência. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Maior confiabilidade da workload: garantindo que as dependências externas estejam consistentemente disponíveis e tenham uma performance ideal. 
+  Detecção e resolução mais rápidas de problemas: identificação e resolução proativa de problemas com dependências antes que elas afetem a workload. 
+  Visão abrangente: obtendo uma visão holística dos componentes internos e externos que influenciam a integridade da workload. 
+  Escalabilidade aprimorada da workload: entendendo os limites de escalabilidade e as características de performance das dependências externas. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Implemente a telemetria de dependências começando com a identificação dos serviços, da infraestrutura e dos processos dos quais a workload depende. Quantifique quais são as boas condições quando essas dependências estão funcionando conforme o esperado e determine quais dados são necessários para medi-las. Com essas informações, você pode criar painéis e alertas que fornecem insights para suas equipes de operações sobre o estado dessas dependências. Use ferramentas da AWS para descobrir e quantificar os impactos quando as dependências não puderem desempenhar conforme necessário. Revise continuamente sua estratégia para considerar as mudanças nas prioridades, metas e insights obtidos. 

### Etapas da implementação
<a name="implementation-steps"></a>

 Para implementar a telemetria de dependências de forma eficaz: 

1.  **Identifique dependências externas:** colabore com as partes interessadas para identificar as dependências externas das quais a workload depende. As dependências externas podem abranger serviços como bancos de dados externos, APIs de terceiros, rotas de conectividade de rede para outros ambientes e serviços de DNS. O primeiro passo para uma telemetria de dependências eficaz é entender de forma abrangente quais são essas dependências. 

1.  **Desenvolva uma estratégia de monitoramento:** depois de ter uma visão clara de suas dependências externas, elabore uma estratégia de monitoramento personalizada para elas. Isso envolve entender a importância de cada dependência, seu comportamento esperado e quaisquer contratos ou metas de nível de serviço associados (SLA ou SLTs). Configure alertas proativos para receber notificações sobre mudanças de status ou desvios de performance. 

1.  **Utilize o [Amazon CloudWatch Internet Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html):** ele oferece informações sobre a internet global, ajudando a entender interrupções que podem afetar suas dependências externas. 

1.  **Mantenha-se informado com o [AWS Health Dashboard](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/):** ele fornece alertas e orientações de correção quando a AWS está enfrentando eventos que podem impactar seus serviços. 

1.  **Instrumente sua aplicação com o [AWS X-Ray](https://aws.amazon.com/xray/):** o AWS X-Ray fornece informações sobre a performance das aplicações e de suas respectivas dependências subjacentes. Ao rastrear as solicitações do início ao fim, você pode identificar gargalos ou falhas nos serviços ou componentes externos dos quais sua aplicação depende. 

1.  **Use o [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/):** esse serviço orientado por machine learning identifica problemas operacionais, prevê quando problemas críticos podem ocorrer e recomenda ações específicas a serem tomadas. Ele é inestimável para obter informações sobre dependências e determinar que elas não são a fonte dos problemas operacionais. 

1.  **Monitore regularmente:** monitore continuamente métricas e logs relacionados a dependências externas. Configure alertas para comportamento inesperado ou diminuição de performance. 

1.  **Valide após as alterações:** sempre que houver uma atualização ou alteração em qualquer uma das dependências externas, valide sua performance e verifique o alinhamento com os requisitos da sua aplicação. 

 **Nível de esforço do plano de implementação:** médio 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS04-BP01 Identificar os indicadores-chave de performance](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementar a telemetria de aplicações](ops_observability_application_telemetry.md) 
+  [OPS04-BP03 Implementar a telemetria da experiência do usuário](ops_observability_customer_telemetry.md) 
+  [OPS04-BP05 Implementar rastreamento distribuído](ops_observability_dist_trace.md) 

 **Documentos relacionados:** 
+ [ O que é o AWS Health? ](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [ Uso do Amazon CloudWatch Internet Monitor ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html)
+ [Guia do desenvolvedor do AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Guia do usuário do Amazon DevOps Guru ](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)

 **Vídeos relacionados:** 
+ [ Visibility into how internet issues impact app performance ](https://www.youtube.com/watch?v=Kuc_SG_aBgQ)
+ [ Introduction to Amazon DevOps Guru (Introdução ao Amazon DevOps Guru) ](https://www.youtube.com/watch?v=2uA8q-8mTZY)

 **Exemplos relacionados:** 
+ [ Gaining operational insights with AIOps using Amazon DevOps Guru ](https://catalog.us-east-1.prod.workshops.aws/workshops/f92df379-6add-4101-8b4b-38b788e1222b/en-US)
+ [AWS Health Aware ](https://github.com/aws-samples/aws-health-aware/)

# OPS04-BP05 Implementar rastreamento distribuído
<a name="ops_observability_dist_trace"></a>

 O rastreamento distribuído oferece uma maneira de monitorar e visualizar solicitações à medida que elas percorrem vários componentes de um sistema distribuído. Ao capturar dados de rastreamento de várias fontes e analisá-los em uma visão unificada, as equipes podem entender melhor como as solicitações fluem, onde existem gargalos e onde os esforços de otimização devem se concentrar. 

 **Resultado desejado:** Obtenha uma visão holística das solicitações que fluem pelo seu sistema distribuído, permitindo depuração precisa, desempenho otimizado e experiências de usuário aprimoradas. 

 **Antipadrões comuns:** 
+  Instrumentação inconsistente: nem todos os serviços em um sistema distribuído são instrumentados para rastreamento. 
+  Ignorar a latência: foco apenas nos erros e sem considerar a latência ou as degradações graduais do desempenho. 

 **Benefícios de estabelecer esta prática recomendada:** 
+ Visão geral abrangente do sistema: visualização de todo o caminho das solicitações, da entrada à saída.
+  Depuração aprimorada: identificação rápida de onde ocorrem falhas ou problemas de desempenho. 
+  Experiência de usuário aprimorada: monitoramento e otimização com base nos dados reais do usuário, garantindo que o sistema atenda às demandas do mundo real. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Comece identificando todos os elementos da workload que exigem instrumentação. Depois que todos os componentes forem contabilizados, utilize ferramentas como o AWS X-Ray e o OpenTelemetry para coletar dados de rastreamento para análise com ferramentas como o X-Ray e o Amazon CloudWatch ServiceLens Map. Faça avaliações regulares com desenvolvedores e complemente essas discussões com ferramentas como Amazon DevOps Guru X-Ray Analytics e X-Ray Insights para ajudar a fazer descobertas mais profundas. Estabeleça alertas a partir de dados de rastreamento para notificar quando os resultados, conforme definido no plano de monitoramento da workload, estiverem em risco. 

### Etapas da implementação
<a name="implementation-steps"></a>

 Para implementar o rastreamento distribuído de forma eficaz: 

1.  **Use o [AWS X-Ray](https://aws.amazon.com/xray/):** integre o X-Ray à sua aplicação para obter informações sobre seu comportamento, entender seu desempenho e identificar gargalos. Utilize o X-Ray Insights para análise automática de rastreamento. 

1.  **Instrumente seus serviços:** verifique se cada serviço, de uma função do [AWS Lambda](https://aws.amazon.com/lambda/) a uma [instância do EC2](https://aws.amazon.com/ec2/), envia dados de rastreamento. Quanto mais serviços você instrumentar, mais clara será a visão completa. 

1.  **incorpore o [monitoramento de usuários reais do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) e [o monitoramento sintético](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html):** integre o monitoramento de usuários reais (RUM) e o monitoramento sintético com o X-Ray. Isso permite capturar experiências reais do usuário e simular as interações do usuário para identificar possíveis problemas. 

1.  **Use o [agente do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html):** o agente pode enviar rastreamentos a partir do X-Ray ou do OpenTelemetry, aumentando a profundidade dos insights obtidos. 

1.  **Use o [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/):** o DevOps Guruusa dados do X-Ray, CloudWatch, AWS Config e AWS CloudTrail para fornecer recomendações práticas. 

1.  **Analise os rastreamentos:** analise regularmente os dados de rastreamento para discernir padrões, anomalias ou gargalos que possam afetar o desempenho de sua aplicação. 

1.  **Configure alertas:** configure os alarmes no [CloudWatch](https://aws.amazon.com/cloudwatch/) para padrões incomuns ou latências estendidas, permitindo o tratamento proativo de problemas. 

1.  **Melhoria contínua:** revise sua estratégia de rastreamento à medida que os serviços são adicionados ou modificados para capturar todos os pontos de dados relevantes. 

 **Nível de esforço do plano de implementação:** médio 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS04-BP01 Identificar os indicadores-chave de performance](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementar a telemetria de aplicações](ops_observability_application_telemetry.md) 
+  [OPS04-BP03 Implementar a telemetria da experiência do usuário](ops_observability_customer_telemetry.md) 
+  [OPS04-BP04 Implementar a telemetria de dependências](ops_observability_dependency_telemetry.md) 

 **Documentos relacionados:** 
+ [ Guia do desenvolvedor do AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Guia do usuário do agente do Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [ Guia do usuário do Amazon DevOps Guru ](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)

 **Vídeos relacionados:** 
+ [ Use AWS X-Ray Insights (Use o AWS X-Ray Insights) ](https://www.youtube.com/watch?v=tl8OWHl6jxw)
+ [AWS on Air ft. Observability: Amazon CloudWatch and AWS X-Ray (Observabilidade: Amazon CloudWatch e AWS X-Ray) ](https://www.youtube.com/watch?v=qBDBnPkZ-KI)

 **Exemplos relacionados:** 
+ [ Instrumentação da aplicação com AWS X-Ray](https://aws.amazon.com/getting-started/hands-on/distributed-tracing-with-xray/)

# OPERAÇÕES 5. Como reduzir defeitos, facilitar a correção e melhorar o fluxo na produção?
<a name="ops-05"></a>

 Adote abordagens que melhoram o fluxo de alterações na produção, que acionem refatoração, feedback rápido sobre a qualidade e correção de erros. Isso acelera as alterações benéficas que entram na produção, limita os problemas implantados e alcança a rápida identificação e correção dos problemas introduzidos pelas atividades de implantação. 

**Topics**
+ [OPS05-BP01 Usar o controle de versão](ops_dev_integ_version_control.md)
+ [OPS05-BP02 Testar e valide as alterações](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP03 Usar sistemas de gerenciamento de configuração](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 Usar sistemas de gerenciamento de compilação e de implantação](ops_dev_integ_build_mgmt_sys.md)
+ [OPS05-BP05 Executar o gerenciamento de patches](ops_dev_integ_patch_mgmt.md)
+ [OPS05-BP06 Compartilhar os padrões de design](ops_dev_integ_share_design_stds.md)
+ [OPS05-BP07 Implementar práticas para aprimorar a qualidade do código](ops_dev_integ_code_quality.md)
+ [OPS05-BP08 Usar vários ambientes](ops_dev_integ_multi_env.md)
+ [OPS05-BP09 Fazer alterações frequentes, pequenas e reversíveis](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 Automatizar totalmente a integração e a implantação](ops_dev_integ_auto_integ_deploy.md)

# OPS05-BP01 Usar o controle de versão
<a name="ops_dev_integ_version_control"></a>

 Use o controle de versão para ativar o rastreamento de alterações e liberações. 

 Muitos serviços da AWS oferecem recursos de controle de versão. Use um sistema de revisão ou controle de origem como o [o AWS CodeCommit](https://aws.amazon.com/codecommit/) para gerenciar código e outros artefatos, como modelos do [AWS CloudFormation](https://aws.amazon.com/cloudformation/) com controle de versão da sua infraestrutura. 

 **Resultado desejado:** Suas equipes colaboram no código. Quando mesclado, o código é consistente e nenhuma alteração é perdida. Os erros são facilmente revertidos por meio do versionamento correto. 

 **Antipadrões comuns:** 
+  Você está desenvolvendo e armazenando seu código na estação de trabalho. Você teve uma falha de armazenamento irrecuperável na estação de trabalho e seu código foi perdido. 
+  Depois de substituir o código existente pelas alterações, você reinicia a aplicação e ela deixa de ser operável. Não é possível reverter a alteração. 
+  Você tem um bloqueio de gravação em um arquivo de relatório que outra pessoa precisa editar. Ela entra em contato com você solicitando que você interrompa o trabalho para que ela possa concluir as tarefas. 
+  Sua equipe de pesquisa tem trabalhado em uma análise detalhada que moldará seu trabalho futuro. Alguém salvou acidentalmente a lista de compras sobre relatório final. Não é possível reverter a alteração e você terá que recriar o relatório. 

 **Benefícios de estabelecer esta prática recomendada:** Ao usar recursos de versionamento, você pode reverter facilmente para bons estados conhecidos, versões anteriores e limitar o risco de perda de ativos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Mantenha ativos em repositórios controlados por versão. Fazer isso oferece suporte para o rastreamento de alterações, a implantação de novas versões, a detecção de alterações nas versões existentes e a reversão para versões anteriores (por exemplo, a reversão para um estado bom e conhecido no caso de uma falha). Integre os recursos de controle de versão dos sistemas de gerenciamento de configurações aos seus procedimentos. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS05-BP04 Usar sistemas de gerenciamento de compilação e de implantação](ops_dev_integ_build_mgmt_sys.md) 

 **Documentos relacionados:** 
+  [O que é o AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

 **Vídeos relacionados:** 
+  [Introduction to AWS CodeCommit (Introdução ao AWS CodeCommit)](https://youtu.be/46PRLMW8otg) 

# OPS05-BP02 Testar e valide as alterações
<a name="ops_dev_integ_test_val_chg"></a>

 Cada alteração implantada deve ser testada para evitar erros na produção. A prática recomendada concentra-se em testar alterações do controle de versão na build de artefato. Além das alterações do código da aplicação, o teste deve incluir infraestrutura, configuração, controles de segurança e procedimentos de operações. O teste assume muitas formas, desde testes de unidade à análise dos componentes do software (SCA). Mova os testes mais para a esquerda na integração do software e o processo de entrega resultará em maior certeza da qualidade do artefato. 

 Sua organização deve desenvolver padrões de teste para todos os artefatos de software. Os testes automatizados reduzem o trabalho e evitam erros de testes manuais. Os testes manuais podem ser necessários em alguns casos. Os desenvolvedores precisam ter acesso aos resultados dos testes automatizados para criar loops de feedback que melhorem a qualidade do software. 

 **Resultado desejado:** As alterações do software são testadas antes de serem entregues. Os desenvolvedores têm acesso aos resultados e validações dos testes. Sua organização tem um padrão de testes que se aplica a todas as alterações do software. 

 **Antipadrões comuns:** 
+ Você implanta uma nova alteração do software sem nenhum teste. Ele não é executado na produção, o que ocasiona uma interrupção.
+ Novos grupos de segurança são implantados com o CloudFormation sem serem testados em um ambiente de pré-produção. Os grupos de segurança tornam sua aplicação inacessível para seus clientes.
+ Um método é modificado, mas não há testes de unidade. O software falha quando é implantado em produção.

 **Benefícios de estabelecer esta prática recomendada:** A taxa de falha de alteração de implantações de software é reduzida. A qualidade do software é aprimorada. Os desenvolvedores aumentaram a conscientização sobre a viabilidade do código deles. As políticas de segurança podem ser distribuídas com confiança para apoiar a conformidade da organização. Alterações da infraestrutura, como atualizações da política de ajuste de escala automático, são testadas com antecedência para atender às necessidades de tráfego. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Testes são realizados em todas as alterações, desde o código da aplicação à infraestrutura, como parte de sua prática de integração contínua. Os resultados dos testes são publicados para que os desenvolvedores tenham feedback rápido. Sua organização tem um padrão de testes de que todas as alterações devem ser aprovadas. 

 **Exemplo de clientes** 

 Como parte do pipeline de integração contínua, a AnyCompany Retail realiza alguns tipos de teste em todos os artefatos de software. Eles praticam desenvolvimento orientado a testes para que todo o software tenha testes de unidade. Depois que o artefato é criado, eles executam testes completos. Depois que a primeira etapa de testes é concluída, eles executam uma verificação de segurança da aplicação estática, que procura vulnerabilidades conhecidas. Os desenvolvedores recebem mensagens à medida que cada gate de testes é aprovado. Depois que todos os testes são concluídos, o artefato de software é armazenado em um repositório de artefatos. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Trabalhe com partes interessadas em sua organização para desenvolver um padrão de testes para artefatos de software. Em quais testes padrão todos os artefatos devem ser aprovados? Há requisitos de conformidade ou governança que devem ser incluídos na cobertura de testes? Você precisa realizar testes de qualidade de código? Quando os testes são concluídos, quem precisa saber? 

   1.  A [arquitetura de referência de pipeline de implantação da AWS](https://pipelines.devops.aws.dev/) contém uma lista confiável de tipos de testes que podem ser conduzidos em artefatos de software como parte de um pipeline de integração. 

1.  Instrumente sua aplicação com os testes necessários com base em seu padrão de testes de software. Cada conjunto de testes deve ser concluído em menos de dez minutos. Os testes devem ser executados como parte de um pipeline de integração. 

   1.  [O Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) pode testar seu código de aplicação quanto a defeitos. 

   1.  Você pode usar o [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) para realizar testes em artefatos de software. 

   1.  [O AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) pode orquestrar seus testes de software em um pipeline. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS05-BP01 Usar o controle de versão](ops_dev_integ_version_control.md) 
+  [OPS05-BP06 Compartilhar os padrões de design](ops_dev_integ_share_design_stds.md) 
+  [OPS05-BP10 Automatizar totalmente a integração e a implantação](ops_dev_integ_auto_integ_deploy.md) 

 **Documentos relacionados:** 
+ [ Adopt a test-driven development approach (Adotar uma abordagem de desenvolvimento orientada a testes) ](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [ Automated CloudFormation Testing Pipeline with TaskCat and CodePipeline (Pipeline de teste do CloudFormation automatizado com TaskCat e CodePipeline) ](https://aws.amazon.com/blogs/devops/automated-cloudformation-testing-pipeline-with-taskcat-and-codepipeline/)
+ [ Building end-to-end AWS DevSecOps CI/CD pipeline with open source SCA, SAST, and DAST tools (Criar um pipeline de CI/CD completo do AWS DevSecOps e ferramentas DAST) ](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
+ [ Getting started with testing serverless applications (Conceitos básicos de testes de aplicações com tecnologia sem servidor) ](https://aws.amazon.com/blogs/compute/getting-started-with-testing-serverless-applications/)
+ [ My CI/CD pipeline is my release captain (Meu pipeline de CI/CD é meu capitão de lançamentos) ](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [ Whitepaper: Practicing Continuous Integration and Continuous Delivery on AWS (Praticar a integração e entrega contínuas na AWS) ](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)

 **Vídeos relacionados:** 
+ [AWS re:Invent 2020: Testable infrastructure: Integration testing on AWS (AWS re:Invent 2020: infraestrutura testável: teste de integração na AWS) ](https://www.youtube.com/watch?v=KJC380Juo2w)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development (AWS Summit ANZ 2021: conduzir uma estratégia de primeiro teste com o CDK e desenvolvimento orientado a testes) ](https://www.youtube.com/watch?v=1R7G_wcyd3s)
+ [ Testing Your Infrastructure as Code with AWS CDK (Testar sua infraestrutura como código com o AWS CDK) ](https://www.youtube.com/watch?v=fWtuwGSoSOU)

 **Recursos relacionados:** 
+ [AWS Deployment Pipeline Reference Architecture - Application (Arquitetura de referência de pipeline de implantação da AWS: aplicação) ](https://pipelines.devops.aws.dev/application-pipeline/index.html)
+ [AWS Kubernetes DevSecOps Pipeline (Pipeline do AWS Kubernetes DevSecOps) ](https://github.com/aws-samples/devsecops-cicd-containers)
+ [ Workshop sobre política como código: desenvolvimento orientado a testes ](https://catalog.us-east-1.prod.workshops.aws/workshops/9da471a0-266a-4d36-8596-e5934aeedd1f/en-US/pac-tools/cfn-guard/tdd)
+ [ Run unit tests for a Node.js application from GitHub by using AWS CodeBuild (Executar testes de unidade para uma aplicação Node.js do GitHub usando o AWS CodeBuild) ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.html)
+ [ Use Serverspec for test-driven development of infrastructure code (Usar o Serverspec para desenvolvimento orientado a testes do código de infraestrutura) ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/use-serverspec-for-test-driven-development-of-infrastructure-code.html)

 **Serviços relacionados:** 
+  [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 
+  [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
+  [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 

# OPS05-BP03 Usar sistemas de gerenciamento de configuração
<a name="ops_dev_integ_conf_mgmt_sys"></a>

 Use os sistemas de gerenciamento de configuração para fazer e rastrear alterações nas configurações. Esses sistemas reduzem os erros causados pelos processos manuais e o nível de esforço para implantar as alterações. 

 O gerenciamento da configuração estática define valores ao inicializar um recurso que deve permanecer consistente durante todo o tempo de vida do recurso. Alguns exemplos incluem a definição da configuração do servidor web ou de aplicação em uma instância, ou a definição da configuração de um serviço da AWS no [Console de gerenciamento da AWS](https://docs.aws.amazon.com/awsconsolehelpdocs/index.html) ou por meio da [AWS CLI](https://aws.amazon.com/cli/). 

 O gerenciamento da configuração dinâmica define valores na inicialização que podem ou devem ser alterados durante o tempo de vida de um recurso. Por exemplo, é possível definir a alternância de um recurso para ativar uma funcionalidade no código por meio de uma alteração na configuração, ou alterar o nível de detalhes do log durante um incidente para capturar mais dados e desfazer a alteração depois do incidente, eliminando os logs agora desnecessários e a despesa associada. 

 Na AWS, você pode usar o [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) para monitorar continuamente as configurações de seus recursos da AWS [entre contas e Regiões](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html). Isso ajuda a rastrear o histórico da configuração, compreender como a alteração de uma configuração afeta outros recursos e auditá-la em relação a configurações esperadas ou desejadas, usando o [Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) e [pacotes de conformidade do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html). 

 Se tiver configurações dinâmicas em suas aplicações executadas em instâncias do Amazon EC2, AWS Lambda, contêineres, aplicativos móveis ou dispositivos de IoT, você pode usar o [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) para configurá-las, validá-las, implantá-las e monitorá-las em seus ambientes. 

 Na AWS, é possível criar pipelines de integração contínua/implantação contínua (CI/CD) usando serviços como as [Ferramentas de desenvolvedor da AWS](https://aws.amazon.com/products/developer-tools/) (por exemplo: [o AWS CodeCommit](https://aws.amazon.com/codecommit/), o [AWS CodeBuild](https://aws.amazon.com/codebuild/), o [AWS CodePipeline](https://aws.amazon.com/codepipeline/), o [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)e o [AWS CodeStar](https://aws.amazon.com/codestar/)). 

 **Resultado desejado:** Você configura, valida e implanta como parte de seu pipeline de integração contínua e entrega contínua (CI/CD). Você monitora para validar se as configurações estão corretas. Isso minimiza qualquer impacto para usuários finais e clientes. 

 **Antipadrões comuns:** 
+  Você atualiza manualmente a configuração do servidor web em toda a frota e vários servidores não respondem devido a erros de atualização. 
+  Você atualiza manualmente a frota do servidor de aplicativos ao longo de muitas horas. A inconsistência na configuração durante a alteração causa comportamentos inesperados. 
+  Alguém atualizou seus grupos de segurança e seus servidores web não estão mais acessíveis. Sem saber o que foi alterado, você gasta muito tempo investigando o problema, ampliando o tempo de recuperação. 
+  Você coloca uma configuração de pré-produção em produção por meio de CI/CD sem validação. Você expõe usuários e clientes a dados e serviços incorretos. 

 **Benefícios de estabelecer esta prática recomendada:** A adoção de sistemas de gerenciamento de configurações reduz o nível de esforço para fazer e rastrear alterações, bem como a frequência de erros causados por procedimentos manuais. Os sistemas de gerenciamento de configuração fornecem garantias com relação aos requisitos regulatórios, de conformidade e de governança. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Os sistemas de gerenciamento de configuração são usados para rastrear e implementar alterações nas configurações de aplicações e ambientes. Os sistemas de gerenciamento de configuração também são usados para reduzir erros causados por processos manuais, tornar as alterações de configuração repetíveis e auditáveis e reduzir o nível de esforço. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Identifique os proprietários da configuração. 

   1.  Informe os proprietários das configurações sobre quaisquer necessidades regulatórias, de conformidade ou de controle. 

1.  Identifique os itens de configuração e os resultados. 

   1.  Os itens de configuração são todas as configurações de aplicações e ambientes afetadas por uma implantação em seu pipeline de CI/CD. 

   1.  Os resultados incluem critérios de sucesso, validação e o que monitorar. 

1.  Selecione ferramentas para gerenciamento de configuração com base nos requisitos de seus negócios e no pipeline de entrega. 

1.  Considere implantações ponderadas, como implantações canário, para alterações significativas na configuração, a fim de minimizar o impacto de configurações incorretas. 

1.  Integre seu gerenciamento de configuração ao seu pipeline de CI/CD. 

1.  Valide todas as alterações enviadas. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS06-BP01 Preparar-se para alterações malsucedidas](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) 
+  [OPS06-BP02 Testar as implantações](ops_mit_deploy_risks_test_val_chg.md) 
+  [OPS06-BP03 Utilizar estratégias de implantação seguras](ops_mit_deploy_risks_deploy_mgmt_sys.md) 
+  [OPS06-BP04 Automatizar os testes e a reversão](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documentos relacionados:** 
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Landing Zone Accelerator (Acelerador de zona de pouso da AWS) ](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [ O que é o AWS Config? ](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+  [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 
+ [ O que é o AWS CloudFormation? ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+  [Ferramentas de desenvolvedor da AWS](https://aws.amazon.com/products/developer-tools/) 

 **Vídeos relacionados:** 
+ [AWS re:Invent 2022 - Proactive governance and compliance for AWS workloads (AWS re:Invent 2022: governança e conformidade proativas para workloads da AWS) ](https://youtu.be/PpUnH9Y52X0?si=82wff87KHXcc6nbT)
+ [AWS re:Invent 2020: Achieve compliance as code using AWS Config (AWS re:Invent 2020: alcance a conformidade como código usando o AWS Config) ](https://youtu.be/m8vTwvbzOfw?si=my4DP0FLq1zwKjho)
+ [ Manage and Deploy Application Configurations with AWS AppConfig (Gerencie e implante configurações de aplicações com o AWS AppConfig) ](https://youtu.be/ztIxMY3IIu0?si=ovYGsxWOBysyQrg0)

# OPS05-BP04 Usar sistemas de gerenciamento de compilação e de implantação
<a name="ops_dev_integ_build_mgmt_sys"></a>

 Use sistemas de gerenciamento de compilação e implantação. Esses sistemas reduzem os erros causados pelos processos manuais e o nível de esforço para implantar as alterações. 

 Na AWS, é possível criar pipelines de integração contínua/implantação contínua (CI/CD) usando serviços como [Ferramentas de desenvolvedor da AWS](https://aws.amazon.com/products/developer-tools/) (por exemplo, AWS CodeCommit, [AWS CodeBuild](https://aws.amazon.com/codebuild/), o [AWS CodePipeline](https://aws.amazon.com/codepipeline/), o [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)e o [AWS CodeStar](https://aws.amazon.com/codestar/)). 

 **Resultado desejado:** Seus sistemas de gerenciamento de compilação e implantação oferecem suporte ao sistema de integração contínua (CI/CD) de sua organização, que fornece recursos para automatizar implementações seguras com as configurações corretas. 

 **Antipadrões comuns:** 
+  Depois de compilar o código no sistema de desenvolvimento e copiar o executável nos sistemas de produção, há uma falha na inicialização. Os arquivos de log locais indicam que a falha ocorreu devido à ausência de dependências. 
+  Você cria a aplicação com êxito com os novos recursos em seu ambiente de desenvolvimento e fornece o código à garantia de qualidade (QA). Ele falha no QA porque não há ativos estáticos. 
+  Na sexta-feira, após muito esforço, você consegue criar a aplicação manualmente em seu ambiente de desenvolvimento, incluindo os recursos recém-codificados. Na segunda-feira, você não consegue repetir as etapas que permitiram criar a aplicação com êxito. 
+  Você executa os testes que criou para a nova versão. Então você passa a próxima semana configurando um ambiente de teste e executando todos os testes de integração existentes, seguidos pelos testes de performance. O novo código tem um impacto inaceitável na performance e deve ser desenvolvido e testado novamente. 

 **Benefícios de estabelecer esta prática recomendada:** Ao fornecer mecanismos para gerenciar atividades de criação e implantação, você reduz o nível de esforço para executar tarefas repetitivas, libera os membros da equipe para se concentrarem em tarefas criativas de alto valor e limita o surgimento de erros provenientes de procedimentos manuais. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Os sistemas de gerenciamento de compilação e implantação são usados para rastrear e implementar mudanças, reduzir erros causados por processos manuais e reduzir o nível de esforço necessário para implantações seguras. Automatize totalmente o pipeline de integração e implantação desde o check-in do código até a compilação, o teste, a implantação e a validação. Isso reduz o tempo de espera, diminui os custos, incentiva o aumento da frequência de mudanças, reduz o nível de esforço e aumenta a colaboração. 

### Etapas da implementação
<a name="implementation-steps"></a>

![\[Diagrama mostrando um pipeline de CI/CD usando o AWS CodePipeline e serviços relacionados\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/deployment-pipeline-tooling.png)


 

1.  Use o AWS CodeCommit para controlar versões, armazenar e gerenciar ativos (como documentos, código-fonte e arquivos binários). 

1.  Use o CodeBuild para compilar seu código-fonte, executar testes de unidade e produzir artefatos prontos para serem implantados. 

1.  Use CodeDeploy como serviço de implantação que automatiza as implantações de aplicações para [Amazon EC2](https://aws.amazon.com/ec2/) instâncias, instâncias on-premises, [funções do AWS Lambda sem servidor](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)ou [Amazon ECS](https://aws.amazon.com/ecs/). 

1.  Monitore suas implantações. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS06-BP04 Automatizar os testes e a reversão](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documentos relacionados:** 
+  [Ferramentas de desenvolvedor da AWS](https://aws.amazon.com/products/developer-tools/) 
+ [ O que é o AWS CodeCommit? ](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
+  [O que é o AWS CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/)
+  [O que é o AWS CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 

 **Vídeos relacionados:** 
+ [AWS re:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS (AWS re:Invent 2022: práticas recomendadas do AWS Well-Architected para DevOps na AWS) ](https://youtu.be/hfXokRAyorA)

# OPS05-BP05 Executar o gerenciamento de patches
<a name="ops_dev_integ_patch_mgmt"></a>

 Execute o gerenciamento de patches para obter recursos, solucionar problemas e manter a conformidade com a governança. Automatize o gerenciamento de patches para reduzir erros causados por processos manuais, escalar e facilitar a realização de patches. 

 O gerenciamento de patches e vulnerabilidades faz parte de suas atividades de gerenciamento de benefícios e riscos. É preferível ter infraestruturas imutáveis e implantar cargas de trabalho em bons estados verificados e conhecidos. Quando isso não é viável, a aplicação de patches é a opção restante. 

 [O Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) fornece pipelines para atualizar as imagens de máquina. Como parte do gerenciamento de patches, considere [Amazon Machine Images](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html       ) (AMIs) usando um [pipeline de imagens AMI](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html) ou imagens de contêiner com um [pipeline de imagens do Docker](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html), enquanto o AWS Lambda fornece padrões para [tempos de execução personalizados e bibliotecas adicionais](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html) para remover vulnerabilidades. 

 Você deve gerenciar atualizações em [Amazon Machine Images](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) para imagens do Linux ou Windows Server usando o [Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/). Você pode usar o [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) com seu pipeline existente para gerenciar imagens do Amazon ECS e gerenciar imagens do Amazon EKS. O Lambda inclui [recursos de gerenciamento de versão](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html). 

 A aplicação de patches não deve ser realizada em sistemas de produção sem antes testá-los em um ambiente seguro. Os patches só deverão ser aplicados se forem compatíveis com um resultado operacional ou comercial. Na AWS, você pode usar o [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) para automatizar o processo de aplicação de patches em sistemas gerenciados e programar a atividade usando o [Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html). 

 **Resultado desejado:** suas imagens de AMI e contêiner foram corrigidas, atualizadas e estão prontas para o lançamento. Você pode acompanhar o status de todas as imagens implantadas e conhecer a conformidade do patch. É possível emitir relatórios do status atual e ter um processo para atender às suas necessidades de conformidade. 

 **Antipadrões comuns:** 
+  Você recebe uma ordem para aplicar todos os novos patches de segurança em até duas horas, resultando em várias interrupções devido à incompatibilidade da aplicação com os patches. 
+  Uma biblioteca sem patches resulta em consequências indesejadas, pois partes desconhecidas usam vulnerabilidades dentro dela para acessar a workload. 
+  Você aplica patches nos ambientes do desenvolvedor automaticamente, sem notificar os desenvolvedores. Você recebe várias reclamações dos desenvolvedores, dizendo que o ambiente deles não está funcionando conforme o esperado. 
+  Você não aplicou patches no software pronto para uso comercial em uma instância persistente. Quando você tiver um problema com o software e entrar em contato com o fornecedor, ele informará que a versão não é compatível e será necessário aplicar patches a um nível específico para receber assistência. 
+  Um patch lançado recentemente para o software de criptografia que você usou tem melhorias significativas de performance. Seu sistema sem patches tem problemas de performance que permanecem enquanto não for feita a aplicação de patches. 
+  Você é notificado sobre uma vulnerabilidade de dia zero que exige uma correção de emergência e precisa fazer isso em todos os seus ambientes manualmente. 

 **Benefícios de estabelecer esta prática recomendada:** Ao estabelecer um processo de gerenciamento de patches, incluindo seus critérios de aplicação de patches e metodologia para distribuição em seus ambientes, você pode escalar e gerar relatórios sobre os níveis de patch. Isso fornece garantias sobre a aplicação de patches de segurança e garante uma visibilidade clara do status das correções conhecidas em vigor. Isso permite a adoção de recursos e capacidades desejados, a remoção rápida de problemas e a conformidade contínua com a governança. Implemente sistemas de gerenciamento de patches e automação para reduzir o nível de esforço na implantação de patches e limitar erros causados por processos manuais. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Aplique patches nos sistemas para corrigir problemas, obter os recursos ou capacidades desejados e permanecer em conformidade com a política de governança e os requisitos de suporte do fornecedor. Em sistemas imutáveis, implante com o conjunto de patches adequado para alcançar o resultado desejado. Automatize o mecanismo de gerenciamento de patches para reduzir o tempo decorrido na aplicação de patches, reduzir erros causados por processos manuais e reduzir o nível de esforço para corrigir. 

### Etapas da implementação
<a name="implementation-steps"></a>

 Para Amazon EC2 Image Builder: 

1.  Usando o Amazon EC2 Image Builder, especifique os detalhes do pipeline: 

   1.  Crie um pipeline de imagens e dê um nome a ele 

   1.  Defina o cronograma e o fuso horário do pipeline 

   1.  Configure todas as dependências 

1.  Escolha uma fórmula: 

   1.  Selecione a fórmula existente ou crie uma nova. 

   1.  Selecione o tipo de imagem. 

   1.  Nomeie e crie a versão da sua fórmula 

   1.  Selecione sua imagem base 

   1.  Adicione componentes de compilação e adicione ao registro de destino 

1.  Opcional: defina sua configuração de infraestrutura. 

1.  Opcional: defina as configurações. 

1.  Revise as configurações. 

1.  Mantenha a higiene da fórmula regularmente. 

 Para o Systems Manager Patch Manager: 

1.  Crie uma lista de referência de patches. 

1.  Selecione um método de operações de definição de caminho. 

1.  Habilite relatórios e escaneamentos de conformidade. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS06-BP04 Automatizar os testes e a reversão](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documentos relacionados:** 
+ [ O que é o Amazon EC2 Image Builder ](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html)
+ [ Crie um pipeline de imagens usando o Amazon EC2 Image Builder ](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)
+ [ Crie um pipeline de imagens de contêiner ](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html)
+  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
+ [ Trabalhar com o Patch Manager ](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-console.html)
+ [ Trabalhar com relatórios de conformidade de patches ](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-compliance-reports.html)
+ [ Ferramentas de desenvolvedor da AWS](https://aws.amazon.com/products/developer-tools)

 **Vídeos relacionados:** 
+  [CI/CD para aplicações de tecnologia sem servidor na AWS](https://www.youtube.com/watch?v=tEpx5VaW4WE) 
+  [Projeto com Ops em mente](https://youtu.be/uh19jfW7hw4) 

   **Exemplos relacionados:** 
+ [ Laboratórios do Well-Architected: Gerenciamento de inventário e patches ](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management)
+ [ Tutoriais do AWS Systems Manager Patch Manager ](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-tutorials.html)

# OPS05-BP06 Compartilhar os padrões de design
<a name="ops_dev_integ_share_design_stds"></a>

 Compartilhe as melhores práticas entre as equipes para aumentar a conscientização e maximizar os benefícios dos esforços de desenvolvimento. Documente-as e mantenha-as atualizadas à medida que sua arquitetura evolui. Se forem aplicados padrões compartilhados na sua organização, será fundamental que haja mecanismos para solicitar adições, alterações e exceções para os padrões. Sem essa opção, os padrões se tornam uma restrição à inovação. 

 **Resultado desejado:** padrões de design são compartilhados entre as equipes nas organizações. Eles são documentados e mantidos atualizados de acordo com a evolução das práticas recomendadas. 

 **Antipadrões comuns:** 
+ Cada uma das duas equipes de desenvolvimento criou um serviço de autenticação de usuários. Os usuários devem manter um conjunto separado de credenciais para cada parte do sistema que desejam acessar. 
+ Cada equipe gerencia sua própria infraestrutura. Um novo requisito de conformidade força uma alteração na infraestrutura e cada equipe o implementa de maneira diferente.

 **Benefícios de estabelecer esta prática recomendada:** o uso dos padrões compartilhados apoia a adoção das práticas recomendadas e maximiza os benefícios dos esforços de desenvolvimento. A documentação e atualização dos padrões de design mantém a organização atualizada com relação às práticas recomendadas e aos requisitos de segurança e conformidade. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Compartilhe as práticas recomendadas, os padrões de design, as listas de verificação, os procedimentos operacionais, as orientações e os requisitos de governança entre equipes. Tenha procedimentos para solicitar alterações, adições e exceções para padrões de design a fim de apoiar a melhoria e a inovação. As equipes devem estar cientes do conteúdo publicado. Tenha um mecanismo para manter os padrões de design atualizados à medida que surgem novas práticas recomendadas. 

 **Exemplo de clientes** 

 A AnyCompany Retail tem uma equipe de arquitetura multifuncional que cria padrões de arquitetura de software. Essa equipe cria a arquitetura com conformidade e governança integradas. As equipes que adotam esses padrões compartilhados recebem os benefícios de ter a conformidade e governança integradas. Elas podem criar rapidamente com base no padrão de design. A equipe de arquitetura se reúne trimestralmente para avaliar os padrões de arquitetura e atualizá-los, se necessário. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Identifique uma equipe multifuncional que seja responsável pelo desenvolvimento e pela atualização dos padrões de design. Essa equipe deverá trabalhar com as partes interessadas na organização para desenvolver os padrões de design, os procedimentos operacionais, as listas de verificações, as orientações e os requisitos de governança. Documente os padrões de design e compartilhe-os na organização. 

   1.  [O AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) pode ser usado para criar portfólios representando os padrões de design usando infraestrutura como código. É possível compartilhar portfólios entre contas. 

1.  Tenha um mecanismo em vigor para manter os padrões de design atualizados à medida que novas práticas recomendadas são identificadas. 

1.  Se os padrões de design forem aplicados centralmente, tenha um processo para solicitar alterações, atualizações e isenções. 

 **Nível de esforço do plano de implementação:** médio. O desenvolvimento de um processo para criar e compartilhar padrões de design pode exigir coordenação e cooperação com as partes interessadas na organização. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS01-BP03 Avaliar os requisitos de governança](ops_priorities_governance_reqs.md) – Os requisitos de governança influenciam os padrões de design. 
+  [OPS01-BP04 Avaliar os requisitos de conformidade](ops_priorities_compliance_reqs.md) – A conformidade é um fator fundamental na criação dos padrões de design. 
+  [OPS07-BP02 Garantir uma análise consistente da prontidão operacional](ops_ready_to_support_const_orr.md) – As listas de verificação de prontidão operacional são um mecanismo para implementar os padrões de design ao projetar a workload. 
+  [OPS11-BP01 Ter um processo para a melhoria contínua](ops_evolve_ops_process_cont_imp.md) – A atualização dos padrões de design faz parte da melhoria contínua. 
+  [OPS11-BP04 Realizar o gerenciamento de conhecimento](ops_evolve_ops_knowledge_management.md) – Como parte da sua prática de gerenciamento de conhecimento, documente e compartilhe os padrões de design. 

 **Documentos relacionados:** 
+ [ Automatizar AWS Backups com AWS Service Catalog](https://aws.amazon.com/blogs/mt/automate-aws-backups-with-aws-service-catalog/)
+ [ Conta do AWS Service Catalog aprimorada para o setor ](https://aws.amazon.com/blogs/mt/aws-service-catalog-account-factory-enhanced/)
+ [ Como o Expedia Group criou uma oferta de banco de dados como serviço (DBaaS) usando o AWS Service Catalog](https://aws.amazon.com/blogs/mt/how-expedia-group-built-database-as-a-service-dbaas-offering-using-aws-service-catalog/)
+ [ Manter a visibilidade sobre o uso dos padrões de arquitetura de nuvem ](https://aws.amazon.com/blogs/architecture/maintain-visibility-over-the-use-of-cloud-architecture-patterns/)
+ [ Simplifique o compartilhamento de seus portfólios do AWS Service Catalog em uma configuração do AWS Organizations](https://aws.amazon.com/blogs/mt/simplify-sharing-your-aws-service-catalog-portfolios-in-an-aws-organizations-setup/)

 **Vídeos relacionados:** 
+ [AWS Service Catalog – conceitos básicos ](https://www.youtube.com/watch?v=A9kKy6WhqVA)
+ [AWS re:Invent 2020: gerencie seus portfólios do AWS Service Catalog como especialista ](https://www.youtube.com/watch?v=lVfXkWHAtR8)

 **Exemplos relacionados:** 
+ [ Arquitetura de referência do AWS Service Catalog](https://github.com/aws-samples/aws-service-catalog-reference-architectures)
+ [ Workshop do AWS Service Catalog](https://catalog.us-east-1.prod.workshops.aws/workshops/d40750d7-a330-49be-9945-cde864610de9/en-US)

 **Serviços relacionados:** 
+  [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) 

# OPS05-BP07 Implementar práticas para aprimorar a qualidade do código
<a name="ops_dev_integ_code_quality"></a>

Implemente práticas para aprimorar a qualidade do código e minimizar os defeitos. Alguns exemplos incluem desenvolvimento orientado por testes, análises de código, adoção de padrões e programação de pares. Incorpore essas práticas em seu processo de entrega e integração contínua. 

 **Resultado desejado:** Sua organização usa práticas recomendadas como análises de código ou programação de pares para melhorar a qualidade do código. Os desenvolvedores e operadores adotam práticas recomendadas de qualidade do código como parte do ciclo de vida de desenvolvimento de software. 

 **Antipadrões comuns:** 
+ Você confirma o código para a ramificação principal da aplicação sem uma análise de código. A alteração é implantada automaticamente na produção e causa uma interrupção.
+  Uma nova aplicação é desenvolvida sem nenhum teste de integração, completo ou de unidade. Não há como testar a aplicação antes da implantação. 
+  Sua equipe faz alterações manuais na produção para solucionar os defeitos. As alterações não passam por testes ou análises de código e não são capturadas nem registradas por processos contínuos de entrega e integração. 

 **Benefícios de estabelecer esta prática recomendada:** Ao adotar práticas para melhorar a qualidade do código, é possível reduzir os problemas surgidos na produção. A qualidade do código aumenta com o uso de práticas recomendadas como programação de pares e análises de código. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Implemente práticas para melhorar a qualidade do código visando a minimizar os defeitos antes que eles sejam implantados. Use práticas como desenvolvimento orientado por testes, análises de código e programação de pares para aumentar a qualidade do desenvolvimento. 

 **Exemplo de clientes** 

 A AnyCompany Retail adota várias práticas para melhorar a qualidade do código. O desenvolvimento orientado por testes foi adotado como padrão para escrever aplicações. Para alguns recursos novos, os desenvolvedores fazem a programação em pares durante um sprint. Cada pull request passa por uma análise de código feita por um desenvolvedor sênior antes de ser integrada e implantada. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Adote práticas de qualidade de código como desenvolvimento orientado por testes, análises de código e programação de pares em seu processo de entrega e integração contínua. Use essas técnicas para melhorar a qualidade do software. 

   1.  [O Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) pode fornecer recomendações de programação para código Java e Python usando machine learning. 

   1.  Você pode criar ambientes de desenvolvimento compartilhados com o [AWS Cloud9,](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) onde você pode colaborar no desenvolvimento de código. 

 **Nível de esforço do plano de implementação:** Médio. Há muitas maneiras de implementar essa prática recomendada, mas pode ser difícil garantir a adesão organizacional. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS05-BP06 Compartilhar os padrões de design](ops_dev_integ_share_design_stds.md) – É possível compartilhar padrões de design como parte de sua prática de qualidade de código. 

 **Documentos relacionados:** 
+ [ Agile Software Guide (Guia do software Agile) ](https://martinfowler.com/agile.html)
+ [My CI/CD pipeline is my release captain (Meu pipeline de CI/CD é meu capitão de lançamentos)](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [ Análises de código automatizadas com o Amazon CodeGuru Reviewer ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [ Adopt a test-driven development approach (Adotar uma abordagem de desenvolvimento orientada a testes) ](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [ How DevFactory builds better applications with Amazon CodeGuru (Como o DevFactory cria melhores aplicações com o Amazon CodeGuru) ](https://aws.amazon.com/blogs/machine-learning/how-devfactory-builds-better-applications-with-amazon-codeguru/)
+ [ On Pair Programming (Sobre a programação de pares) ](https://martinfowler.com/articles/on-pair-programming.html)
+ [ RENGA Inc. automates code reviews with Amazon CodeGuru (RENGA Inc. automatiza análises de código com o Amazon CodeGuru) ](https://aws.amazon.com/blogs/machine-learning/renga-inc-automates-code-reviews-with-amazon-codeguru/)
+ [ The Art of Agile Development: Test-Driven Development (A arte do desenvolvimento ágil: desenvolvimento orientado por testes) ](http://www.jamesshore.com/v2/books/aoad1/test_driven_development)
+ [ Why code reviews matter (and actually save time\$1) (Por que as análises de código são importantes (e economizam tempo\$1) ](https://www.atlassian.com/agile/software-development/code-reviews)

 **Vídeos relacionados:** 
+ [AWS re:Invent 2020: Continuous improvement of code quality with Amazon CodeGuru (AWS re:Invent 2020: melhoria contínua da qualidade do código com o Amazon CodeGuru) ](https://www.youtube.com/watch?v=iX1i35H1OVw)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development (AWS Summit ANZ 2021: conduzir uma estratégia de primeiro teste com o CDK e desenvolvimento orientado a testes) ](https://www.youtube.com/watch?v=1R7G_wcyd3s)

 **Serviços relacionados:** 
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Amazon CodeGuru Profiler ](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+  [AWS Cloud9,](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) 

# OPS05-BP08 Usar vários ambientes
<a name="ops_dev_integ_multi_env"></a>

 Use vários ambientes para experimentar, desenvolver e testar a workload. Use níveis crescentes de controles à medida que os ambientes se aproximam da produção para adquirir confiança de que sua workload operará conforme pretendido quando implantada. 

 **Resultado desejado:** Você tem vários ambientes que refletem suas necessidades de conformidade e governança. Você testa e promove o código por meio de ambientes em seu caminho para a produção. 

 **Antipadrões comuns:** 
+  Você está realizando o desenvolvimento em um ambiente de desenvolvimento compartilhado e outro desenvolvedor substitui suas alterações de código. 
+  Os controles de segurança restritivos em seu ambiente de desenvolvimento compartilhado estão impedindo que você experimente novos serviços e recursos. 
+  Você realiza testes de carga em seus sistemas de produção e causa uma interrupção para seus usuários. 
+  Ocorreu um erro crítico na produção que resulta na perda de dados. No ambiente de produção, você tenta recriar as condições que levaram à perda de dados para identificar como isso aconteceu e impedir a recorrência. Para evitar mais perda de dados durante o teste, você é forçado a tornar indisponível a aplicação para seus usuários. 
+  Você está operando um serviço multilocatário e não consegue oferecer suporte a uma solicitação do cliente para um ambiente dedicado. 
+  Nem sempre você testa, mas, quando o faz, o teste acontece em seu ambiente de produção. 
+  Você acredita que a simplicidade de um único ambiente substitui o escopo do impacto das alterações dentro do ambiente. 

 **Benefícios de estabelecer esta prática recomendada:** Você pode oferecer suporte a vários ambientes simultâneos de desenvolvimento, teste e produção, sem criar conflitos entre desenvolvedores ou comunidades de usuários. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Use vários ambientes e forneça aos desenvolvedores ambientes de sandbox com controles minimizados para permitir a experimentação. Forneça ambientes de desenvolvimento individuais para ajudar o trabalho em paralelo, aumentando a agilidade do desenvolvimento. Implemente controles mais rigorosos nos ambientes ao se aproximar da produção para permitir que os desenvolvedores inovem. Use a infraestrutura como sistemas de gerenciamento de código e configuração para implantar ambientes que são configurados de maneira consistente com os controles presentes na produção para garantir que os sistemas operem conforme o esperado quando implantados. Quando os ambientes não estiverem em uso, desligue-os para evitar custos associados a recursos inativos (por exemplo, sistemas de desenvolvimento à noite e fins de semana). Implante ambientes equivalentes de produção ao carregar o teste para melhorar resultados válidos. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Programador de instâncias na AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
+  [O que é o AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 

# OPS05-BP09 Fazer alterações frequentes, pequenas e reversíveis
<a name="ops_dev_integ_freq_sm_rev_chg"></a>

 Alterações frequentes, pequenas e reversíveis reduzem o escopo e o impacto de uma alteração. Quando usadas em conjunto com sistemas de gerenciamento de mudanças, sistemas de gerenciamento de configuração e sistemas de compilação e entrega, mudanças frequentes, pequenas e reversíveis reduzem o escopo e o impacto de uma mudança. Isso resulta em solução de problemas mais eficaz e correção mais rápida, com a opção de reverter alterações. 

 **Antipadrões comuns:** 
+  Você implanta uma nova versão de sua aplicação trimestralmente com uma janela de alteração que significa que um serviço principal está desativado. 
+  Você frequentemente faz alterações no esquema do banco de dados sem rastrear as alterações nos sistemas de gerenciamento. 
+  Você realiza atualizações manuais no local, substituindo as instalações e configurações existentes e não tem um plano claro de reversão. 

 **Benefícios de estabelecer esta prática recomendada:** Os esforços de desenvolvimento são mais rápidos com a implantação frequente de pequenas mudanças. Quando as alterações são pequenas, é muito mais fácil identificar se elas têm consequências indesejadas e são mais fáceis de serem revertidas. Quando as alterações são reversíveis, há menos risco de implementar a alteração à medida que a recuperação é simplificada. O processo de mudança tem um risco reduzido e o impacto de uma alteração malsucedida é reduzido. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Use alterações frequentes, pequenas e reversíveis para reduzir o escopo e o impacto de uma alteração. Isso facilita a solução de problemas, ajuda a fazer uma correção mais rápida e oferece a opção de reverter uma alteração. Também aumenta a taxa na qual você pode agregar valor aos negócios. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS05-BP03 Usar sistemas de gerenciamento de configuração](ops_dev_integ_conf_mgmt_sys.md) 
+  [OPS05-BP04 Usar sistemas de gerenciamento de compilação e de implantação](ops_dev_integ_build_mgmt_sys.md) 
+  [OPS06-BP04 Automatizar os testes e a reversão](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documentos relacionados:** 
+ [ Implementing Microservices on AWS (Implementação de microsserviços na AWS) ](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Microservices - Observability (Microsserviços: observabilidade) ](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/observability.html)

# OPS05-BP10 Automatizar totalmente a integração e a implantação
<a name="ops_dev_integ_auto_integ_deploy"></a>

 Automatize a construção, implantação e o teste da workload. Isso reduz os erros causados pelos processos manuais e reduz o esforço para implantar alterações. 

 Aplique metadados usando o [Tags de recursos](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) e [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html) seguindo uma estratégia [consistente de marcação](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) para permitir a identificação dos seus recursos. Identifique seus recursos de organização, contabilidade de custos, controles de acesso pensando na execução de atividades operacionais automatizadas. 

 **Resultado desejado:** os desenvolvedores usam ferramentas para entregar códigos e levá-los até a produção. Os desenvolvedores não precisam fazer login no Console de gerenciamento da AWS para fazer atualizações. Há uma trilha de auditoria completa de alterações e configurações, atendendo às necessidades de governança e conformidade. Os processos são repetíveis e padronizados entre as equipes. Os desenvolvedores podem se concentrar no desenvolvimento e na introdução de código, aumentando a produtividade. 

 **Antipadrões comuns:** 
+  Na sexta-feira, você conclui a criação do novo código para a ramificação do recurso. Na segunda-feira, depois de executar os scripts de teste de qualidade de código e cada um dos scripts de teste de unidade, você registra seu código para a próxima versão programada. 
+  Você tem a tarefa de codificar uma correção para um problema crítico que afeta um grande número de clientes em produção. Depois de testar a correção, você confirma o gerenciamento de alterações de e-mail e código para solicitar aprovação para implantá-lo na produção. 
+  Como desenvolvedor, você faz login no Console de gerenciamento da AWS para criar um novo ambiente de desenvolvimento usando métodos e sistemas que não são padrão. 

 **Benefícios de estabelecer esta prática recomendada:** ao implementar sistemas automatizados de gerenciamento de criação e implantação, você reduz os erros causados por processos manuais e o esforço para implantar alterações, ajudando os membros da equipe a se concentrarem na entrega de valor para a empresa. Você aumenta a velocidade de entrega à medida que avança até a produção. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Você usa sistemas de gerenciamento de criação e implantação para rastrear e implementar alterações, reduzir erros causados por processos manuais e reduzir o nível de esforço. Automatize totalmente o pipeline de integração e implantação desde o check-in do código até a compilação, o teste, a implantação e a validação. Isso reduz o tempo de espera, aumenta a frequência de alterações, reduz o nível de esforço, aumenta a velocidade de entrada no mercado, resulta em maior produtividade e aumenta a segurança do seu código à medida que você o leva até a produção. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS05-BP03 Usar sistemas de gerenciamento de configuração](ops_dev_integ_conf_mgmt_sys.md) 
+  [OPS05-BP04 Usar sistemas de gerenciamento de compilação e de implantação](ops_dev_integ_build_mgmt_sys.md) 

 **Documentos relacionados:** 
+  [O que é o AWS CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
+  [O que é o AWS CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 

 **Vídeos relacionados:** 
+ [AWS re\$1:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS](https://youtu.be/hfXokRAyorA)

# OPERAÇÕES 6. Como reduzir os riscos de implantação?
<a name="ops-06"></a>

 Adote abordagens que forneçam feedback rápido sobre a qualidade e alcancem recuperação rápida de alterações que não têm os resultados desejados. O uso dessas práticas reduz o impacto dos problemas introduzidos pela implantação de mudanças. 

**Topics**
+ [OPS06-BP01 Preparar-se para alterações malsucedidas](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Testar as implantações](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 Utilizar estratégias de implantação seguras](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 Automatizar os testes e a reversão](ops_mit_deploy_risks_auto_testing_and_rollback.md)

# OPS06-BP01 Preparar-se para alterações malsucedidas
<a name="ops_mit_deploy_risks_plan_for_unsucessful_changes"></a>

Planeje reverter para um bom estado anterior ou realize reparos no ambiente de produção se a implantação causar um resultado indesejado. Ter uma política para estabelecer esse plano ajuda todas as equipes a desenvolver estratégias para se recuperar de alterações com falha. Alguns exemplos de estratégias são etapas de implantação e reversão, políticas de alteração, sinalizadores de atributos, isolamento de tráfego e mudança de tráfego. Uma única versão pode incluir várias alterações de componentes relacionadas. A estratégia deve fornecer a possibilidade de resistir ou se recuperar de uma falha de qualquer alteração de componente.

 **Resultado desejado:** Você preparou um plano de recuperação detalhado para a alteração, caso ela não tenha êxito. Além disso, você reduziu o tamanho da sua versão para minimizar o impacto potencial em outros componentes da workload. Como resultado, você reduziu o impacto nos negócios ao diminuir o possível tempo de inatividade decorrente de uma alteração malsucedida e aumentou a flexibilidade e a eficiência dos tempos de recuperação. 

 **Antipadrões comuns:** 
+  Você executou uma implantação e seu aplicativo se tornou instável, mas parece haver usuários ativos no sistema. Você precisa decidir se deseja reverter a alteração e afetar os usuários ativos ou esperar para reverter a alteração sabendo que, mesmo assim, os usuários podem ser afetados. 
+  Depois de fazer uma alteração de rotina, os novos ambientes ficam acessíveis, mas uma de suas sub-redes se tornou inacessível. Você precisa decidir se deseja reverter tudo ou tentar corrigir a sub-rede inacessível. Enquanto você estiver fazendo essa determinação, a sub-rede permanecerá inacessível. 
+  Seus sistemas não são arquitetados de uma forma que permite que sejam atualizados com versões menores. Como resultado, você tem dificuldade em reverter essas alterações em massa durante uma implantação com falha. 
+  Você não usa a infraestrutura como código (IaC) e foram feitas atualizações manuais nela que resultaram em uma configuração indesejada. Você não consegue rastrear e reverter com eficácia as alterações manuais. 
+  Como você não mediu o aumento da frequência das implantações, sua equipe não é incentivada a reduzir o tamanho das mudanças e melhorar seus planos de reversão para cada uma delas, gerando mais riscos e maiores taxas de falha. 
+  Você não mede a duração total de uma interrupção causada por alterações malsucedidas. A equipe não consegue priorizar e melhorar a eficácia do processo de implantação e do plano de recuperação. 

 **Benefícios de estabelecer esta prática recomendada:** Ter um plano para se recuperar de mudanças malsucedidas minimiza o tempo médio de recuperação (MTTR) e reduz o impacto nos negócios. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A adoção de uma política e prática documentadas e consistentes por parte das equipes de lançamento permitem que a organização planeje o que deve ocorrer se houver mudanças malsucedidas. A política deve permitir a correção em circunstâncias específicas. Seja qual for a situação, um plano de correção antecipada ou reversão deve ser bem documentado e testado antes da implantação na produção em tempo real, a fim de que o tempo necessário para reverter uma alteração seja minimizado. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Documente as políticas que exigem que as equipes tenham planos efetivos para reverter as mudanças dentro de um período especificado. 

   1.  As políticas devem especificar quando uma situação de correção antecipada é permitida. 

   1.  Exija que um plano de reversão documentado seja acessível a todos os envolvidos. 

   1.  Especifique os requisitos de reversão (por exemplo, quando for constatado que foram implantadas alterações não autorizadas). 

1.  Analise o nível de impacto de todas as mudanças relacionadas a cada componente de uma workload. 

   1.  Permita que alterações repetíveis sejam padronizadas, modeladas e pré-autorizadas se seguirem um fluxo de trabalho consistente que imponha políticas de mudança. 

   1.  Reduza o impacto potencial de qualquer alteração diminuindo o tamanho dela para que a recuperação leve menos tempo e cause um impacto menor nos negócios. 

   1.  Garanta que os procedimentos de reversão revertam o código para um bom estado conhecido a fim de evitar incidentes sempre que possível. 

1.  Integre ferramentas e fluxos de trabalho para aplicar suas políticas de forma programática. 

1.  Torne os dados sobre as alterações visíveis para outros proprietários da workload a fim de melhorar a velocidade do diagnóstico de qualquer alteração malsucedida que não possa ser revertida. 

   1.  Avalie o sucesso dessa prática usando dados de mudança visíveis e identifique melhorias iterativas. 

1.  Use ferramentas de monitoramento para verificar o sucesso ou a falha de uma implantação a fim de acelerar a tomada de decisões sobre a reversão. 

1.  Meça a duração da interrupção durante uma alteração malsucedida para melhorar continuamente seus planos de recuperação. 

 **Nível de esforço do plano de implementação:** médio 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS06-BP04 Automatizar os testes e a reversão](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documentos relacionados:** 
+ [AWS Builders Library \$1 Ensuring Rollback Safety During Deployments ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [ Whitepaper da AWS \$1 Change Management in the Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)

 **Vídeos relacionados:** 
+ [ re:Invent 2019 \$1 A abordagem da Amazon para implantação de alta disponibilidade ](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)

# OPS06-BP02 Testar as implantações
<a name="ops_mit_deploy_risks_test_val_chg"></a>

 Teste os procedimentos de lançamento na pré-produção usando a mesma configuração de implantação, controles de segurança, etapas e procedimentos da produção. Valide se todas as etapas implantadas foram concluídas conforme o esperado, como inspecionar arquivos, configurações e serviços. Teste ainda mais todas as alterações com testes funcionais, de integração e de carga, além de qualquer monitoramento, como verificações de integridade. Ao fazer esses testes, você pode identificar problemas de implantação com antecedência, podendo planejá-los e mitigá-los antes da produção. 

 Você pode criar ambientes paralelos temporários para testar cada alteração. Automatize a implantação dos ambientes de teste usando a infraestrutura como código (IaC) para ajudar a reduzir a quantidade de trabalho envolvido e garantir estabilidade, consistência e entrega mais rápida de atributos. 

 **Resultado desejado:** A organização adota uma cultura de desenvolvimento orientada a testes que inclui testes de implantações. Isso garante que as equipes se concentrem em oferecer valor empresarial em vez de gerenciar lançamentos. As equipes são engajadas desde o início após a identificação dos riscos de implantação para determinar o curso apropriado da mitigação. 

 **Antipadrões comuns:** 
+  Durante as versões de produção, implantações não testadas causam problemas frequentes que exigem soluções e encaminhamento. 
+  Sua versão contém infraestrutura como código (IaC) que atualiza os recursos existentes. Você não tem certeza se a IaC será executada com êxito ou causará impacto nos recursos. 
+  Você implanta um novo atributo na aplicação. Ele não funciona conforme o esperado e não há visibilidade até ser relatado pelos usuários afetados. 
+  Você atualiza seus certificados. Você instala acidentalmente os certificados nos componentes errados, o que não é detectado e afeta os visitantes do site porque não é possível estabelecer uma conexão segura. 

 **Benefícios de estabelecer esta prática recomendada:** Testes extensivos na pré-produção dos procedimentos de implantação, considerando-se que as mudanças introduzidas por eles minimizam o impacto potencial na produção causado pelas etapas de implantação. Isso aumenta a confiança durante o lançamento da produção e minimiza o suporte operacional sem diminuir a velocidade das alterações que estão sendo entregues. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Testar seu processo de implantação é tão importante quanto testar as alterações resultantes da implantação. Isso pode ser realizado testando suas etapas de implantação em um ambiente de pré-produção que se assemelhe o máximo possível à produção. Problemas comuns, como etapas de implantação incompletas ou incorretas, ou configurações incorretas, podem ser detectados como resultado antes da produção. Além disso, você pode testar suas etapas de recuperação. 

 **Exemplo de clientes** 

 Como parte do pipeline de integração e entrega contínuas (CI/CD), a Loja UmaEmpresa executa as etapas definidas necessárias para lançar atualizações de infraestrutura e software para seus clientes em um ambiente semelhante ao de produção. O pipeline é composto por pré-verificações para detectar desvios (detecção de alterações nos recursos executados fora da IaC) nos recursos antes da implantação, bem como validar as ações que a IaC realiza após seu início. Ele valida as etapas de implantação, como verificar se determinados arquivos e configurações estão em vigor e se os serviços estão em execução e respondendo corretamente às verificações de integridade no host local antes de serem registrados novamente no balanceador de carga. Além disso, todas as alterações sinalizam vários testes automatizados, como testes funcionais, de segurança, de regressão, de integração e de carga. 

### Etapas para a implementação
<a name="implementation-steps"></a>

1.  Execute verificações de pré-instalação para espelhar o ambiente de pré-produção na produção. 

   1.  Use [detecção de desvios](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) para detectar quando os recursos foram alterados fora do CloudFormation. 

   1.  Use [conjuntos de alterações](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) para validar se a intenção da atualização da pilha corresponde às ações que o CloudFormation realiza quando o conjunto de alterações é iniciado. 

1.  Isso aciona uma etapa de aprovação manual no [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) para autorizar a implantação no ambiente de pré-produção. 

1.  Use configurações de implantação, como [arquivos do AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html) para definir as etapas de implantação e validação. 

1.  Quando aplicável, [integre o AWS CodeDeploy a outros serviços da AWS](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) ou [integre o AWS CodeDeploy a produtos e serviços de parceiros](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html). 

1.  [Monitore as implantações](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) usando notificações de eventos do Amazon CloudWatch, do AWS CloudTrail e do Amazon SNS. 

1.  Execute testes automatizados pós-implantação, incluindo testes funcionais, de segurança, regressão, integração e carga. 

1.  [Solução de problemas](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) de implantação. 

1.  A validação bem-sucedida das etapas acima deve iniciar um fluxo de trabalho de aprovação manual para autorizar a implantação na produção. 

 **Nível de esforço do plano de implementação:** Alto 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS05-BP02 Testar e valide as alterações](ops_dev_integ_test_val_chg.md) 

 **Documentos relacionados:** 
+ [AWS Builders' Li\$1 Automating safe, hands-off deployments \$1 Test Deployments ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [ Whitepaper da AWS Whitepaper \$1 Practicing Continuous Integration and Continuous Delivery on AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [ A história da Apollo: o mecanismo de implantação da Amazon ](https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html)
+  [How to test and debug AWS CodeDeploy locally before you ship your code](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/) 
+ [ Integrar testes de conectividade de rede com implantação de infraestrutura ](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-network-connectivity-testing-with-infrastructure-deployment/)

 **Vídeos relacionados:** 
+ [ re:Invent 2020 \$1 Testar software e sistemas na Amazon ](https://www.youtube.com/watch?v=o1sc3cK9bMU)

 **Exemplos relacionados:** 
+ [ Tutorial \$1 Deploy and Amazon ECS service with a validation test ](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)

# OPS06-BP03 Utilizar estratégias de implantação seguras
<a name="ops_mit_deploy_risks_deploy_mgmt_sys"></a>

 Implantações seguras de produção controlam o fluxo de mudanças benéficas com o objetivo de minimizar qualquer impacto percebido dessas alterações para os clientes. Os controles de segurança fornecem mecanismos de inspeção para validar os resultados desejados e limitar o escopo do impacto dos defeitos introduzidos pelas alterações ou das falhas de implantação. As implementações seguras podem incluir estratégias como sinalizadores de atributos e implantações one-box, contínuas (versões canário), imutáveis, de divisão de tráfego e azuis/verdes. 

 **Resultado desejado:** sua organização usa um sistema de integração e entrega contínuas (CI/CD) que fornece recursos para automatizar implementações seguras. As equipes devem usar estratégias apropriadas de implantação seguras. 

 **Antipadrões comuns:** 
+  Você implanta uma alteração malsucedida em toda a produção de uma só vez. Como resultado, todos os clientes são afetados simultaneamente. 
+  Um defeito introduzido em uma implantação simultânea em todos os sistemas requer um lançamento de emergência. A correção para todos os clientes leva vários dias. 
+  O gerenciamento da versão de produção requer planejamento e participação de várias equipes. Isso restringe sua capacidade de atualizar atributos com frequência para seus clientes. 
+  Você executa uma implantação mutável modificando os sistemas existentes. Depois de descobrir que a alteração não foi bem-sucedida, você será forçado a modificar os sistemas novamente para restaurar a versão antiga, aumentando o seu tempo de recuperação. 

 **Benefícios de estabelecer esta prática recomendada:** implantações automatizadas equilibram a velocidade das implementações com a entrega consistente de mudanças benéficas aos clientes. Limitar o impacto evita falhas de implantação dispendiosas e maximiza a capacidade das equipes de responder às falhas de forma eficiente. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Falhas na entrega contínua podem levar à redução da disponibilidade do serviço e a uma experiência ruim para o cliente. Para maximizar a taxa de implantações bem-sucedidas, implemente controles de segurança no processo de lançamento de ponta a ponta para minimizar os erros de implantação e eliminar as falhas. 

 **Exemplo de clientes** 

 A Loja UmaEmpresa tem a missão de alcançar implantações com tempo de inatividade entre mínimo e zero, isto é, sem impacto perceptível para seus usuários durante as implantações. Para fazer isso, a empresa estabeleceu padrões de implantação (consulte o diagrama de fluxo de trabalho a seguir), como implantações azuis/verdes e contínuas. Todas as equipes adotam um ou mais desses padrões no pipeline de CI/CD. 


| Fluxo de trabalho do CodeDeploy para Amazon EC2 | Fluxo de trabalho do CodeDeploy para Amazon ECS | Fluxo de trabalho do CodeDeploy para Lambda | 
| --- | --- | --- | 
|  ![\[Fluxo do processo de implantação do Amazon EC2\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/deployment-process-ec2.png)  |  ![\[Fluxo do processo de implantação do Amazon ECS\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/deployment-process-ecs.png)  |  ![\[Fluxo do processo de implantação do Lambda\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/deployment-process-lambda.png)  | 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Use um fluxo de trabalho de aprovação para iniciar a sequência das etapas de implantação na promoção para implantação. 

1.  Use um sistema de implantação automatizado, como o [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)As opções de implantação do AWS CodeDeploy [incluem](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html) implantações locais do EC2/on-premises e implantações azuis/verdes do EC2/on-premises, do AWS Lambda e do Amazon ECS (consulte o diagrama de fluxo de trabalho anterior). 

   1.  Quando aplicável, [integre o AWS CodeDeploy a outros serviços da AWS](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) ou [integre o AWS CodeDeploy a produtos e serviços de parceiros](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html). 

1.  Use implantações azuis/verdes para bancos de dados, como [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) e o [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html). 

1.  [Monitore as implantações](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) usando notificações de eventos do Amazon CloudWatch, do AWS CloudTrail e do Amazon SNS. 

1.  Realize testes automatizados pós-implantação, incluindo testes funcionais, de segurança, regressão, integração e testes de carga. 

1.  [Solução de problemas](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) de implantação. 

 **Nível de esforço do plano de implementação:** médio 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS05-BP02 Testar e valide as alterações](ops_dev_integ_test_val_chg.md) 
+  [OPS05-BP09 Fazer alterações frequentes, pequenas e reversíveis](ops_dev_integ_freq_sm_rev_chg.md) 
+  [OPS05-BP10 Automatizar totalmente a integração e a implantação](ops_dev_integ_auto_integ_deploy.md) 

 **Documentos relacionados:** 
+ [AWS Builders Library \$1 Automating safe, hands-off deployments \$1 Production deployments ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS Builders Library \$1 My CI/CD pipeline is my release captain \$1 Safe, automatic production releases](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [Whitepaper da AWS \$1 Practicing Continuous Integration and Continuous Delivery on AWS \$1 Deployment methods](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [Guia do usuário do AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [Working with deployment configurations in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [Set up an API Gateway canary release deployment ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Amazon ECS Deployment Types](https://docs.aws.amazon.com/)
+ [Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS](https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/)
+ [Blue/Green deployments with AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)

 **Vídeos relacionados:** 
+ [re:Invent 2020 \$1 Sem intervenção manual: como automatizar os pipelines de entrega contínua na Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 A abordagem da Amazon para implantação de alta disponibilidade](https://www.youtube.com/watch?v=bCgD2bX1LI4)

 **Exemplos relacionados:** 
+ [Try a Sample Blue/Green Deployment in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [Workshop \$1 Buiding CI/CD pipelines for Lambda canary deployments using AWS CDK](https://catalog.us-east-1.prod.workshops.aws/workshops/5195ab7c-5ded-4ee2-a1c5-775300717f42/en-US)
+ [Workshop \$1 Implantação canário e azul/verde para o EKS e o ECS](https://catalog.us-east-1.prod.workshops.aws/workshops/2175d94a-cd79-4ed2-8e7e-1f0dd1956a3a/en-US)
+ [Workshop \$1 Criar um pipeline de CI/CD entre contas](https://catalog.us-east-1.prod.workshops.aws/workshops/00bc829e-fd7c-4204-9da1-faea3cf8bd88/en-US)

# OPS06-BP04 Automatizar os testes e a reversão
<a name="ops_mit_deploy_risks_auto_testing_and_rollback"></a>

 Para aumentar a velocidade, a confiabilidade e a confiança do seu processo de implantação, tenha uma estratégia para testes automatizados e recursos de reversão em ambientes de pré-produção e produção. Automatize os testes ao implantar na produção para simular interações entre humanos e sistemas que verifiquem as alterações que estão sendo implantadas. Automatize a reversão para voltar rapidamente a um estado anterior em boas condições. A reversão deve ser iniciada automaticamente em condições predefinidas, como quando o resultado desejado da alteração não é alcançado ou quando o teste automatizado falha. A automação dessas duas atividades melhora a taxa de sucesso das implantações, minimiza o tempo de recuperação e reduz o impacto potencial nos negócios. 

 **Resultado desejado:** Os testes automatizados e as estratégias de reversão são integrados ao pipeline de integração e entrega contínuas (CI/CD). O monitoramento é capaz de validar seus critérios de sucesso e iniciar a reversão automática em caso de falha. Isso minimiza qualquer impacto para usuários finais e clientes. Por exemplo, quando todos os resultados do teste são satisfatórios, você promove seu código no ambiente de produção em que o teste de regressão automatizado é iniciado, utilizando os mesmos casos de teste. Se os resultados do teste de regressão não corresponderem às expectativas, a reversão automática será iniciada no fluxo de trabalho do pipeline. 

 **Antipadrões comuns:** 
+  Seus sistemas não são arquitetados de uma forma que permite que sejam atualizados com versões menores. Como resultado, você tem dificuldade em reverter essas alterações em massa durante uma implantação com falha. 
+  O processo de implantação consiste em uma série de etapas manuais. Depois de implantar as alterações na workload, você inicia os testes pós-implantação. Após o teste, você percebe que a workload está inoperante e os clientes estão desconectados. Em seguida, você começa a reverter para a versão anterior. Todas essas etapas manuais atrasam a recuperação geral do sistema e causam um impacto prolongado para os clientes. 
+  Você passou um tempo desenvolvendo casos de teste automatizados para funcionalidades que não são usadas com frequência na aplicação, minimizando o retorno sobre o investimento no recurso de teste automatizado. 
+  Sua versão é composta de atualizações de aplicações, infraestrutura, patches e configuração que são independentes umas das outras. No entanto, você tem um único pipeline de CI/CD que fornece todas as alterações de uma só vez. Uma falha em um componente força você a reverter todas as alterações, tornando a reversão complexa e ineficiente. 
+  A equipe conclui o trabalho de codificação no primeiro sprint e inicia o trabalho no segundo sprint, mas seu plano não incluiu testes até o terceiro sprint. Como resultado, os testes automatizados revelaram defeitos do primeiro sprint que precisavam ser resolvidos antes que o teste dos resultados do segundo sprint pudesse ser iniciado, adiando todo o lançamento e desvalorizando seus testes automatizados. 
+  Seus casos de teste de regressão automatizados para a versão de produção estão completos, mas você não está monitorando a integridade da workload. Como você não tem visibilidade sobre se o serviço foi reiniciado, você não tem certeza se a reversão é necessária ou se ela já ocorreu. 

 **Benefícios de estabelecer esta prática recomendada:** O teste automatizado aumenta a transparência do processo de teste e a capacidade de abranger mais atributos em um período mais curto. Ao testar e validar as mudanças na produção, você pode identificar problemas imediatamente. A melhoria na consistência com ferramentas de teste automatizadas permite uma melhor detecção de defeitos. Ao reverter automaticamente para a versão anterior, o impacto sobre seus clientes é minimizado. A reversão automatizada acaba inspirando mais confiança em seus recursos de implantação ao reduzir o impacto nos negócios. No geral, esses recursos reduzem o tempo de entrega e, ao mesmo tempo, garantem a qualidade. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Automatize os testes dos ambientes implantados para confirmar os resultados desejados mais rapidamente. Automatize a reversão para um bom estado anterior conhecido quando os resultados predefinidos não forem alcançados, para minimizar o tempo de recuperação e reduzir os erros causados por processos manuais. Integre ferramentas de teste com seu fluxo de trabalho de pipeline para testar e minimizar as entradas manuais de forma consistente. Priorize a automação de casos de teste, como aqueles que mitigam os maiores riscos e precisam ser testados com frequência a cada alteração. Além disso, automatize a reversão com base em condições específicas predefinidas no plano de teste. 

### Etapas para a implementação
<a name="implementation-steps"></a>

1.  Estabeleça um ciclo de vida de teste para o ciclo de vida de desenvolvimento que defina cada estágio do processo de teste, desde o planejamento dos requisitos até o desenvolvimento do caso de teste, a configuração da ferramenta, o teste automatizado e o encerramento do caso de teste. 

   1.  Crie uma abordagem de teste específica para workloads com base em sua estratégia geral de teste. 

   1.  Considere uma estratégia de teste contínuo, quando apropriado, durante o ciclo de vida do desenvolvimento. 

1.  Selecione ferramentas automatizadas para testes e reversões com base em seus requisitos de negócios e investimentos em pipeline. 

1.  Decida quais casos de teste você deseja automatizar e quais deverão ser executados manualmente. Eles podem ser definidos com base na prioridade do valor comercial do atributo que está sendo testado. Alinhe todos os membros da equipe a esse plano e verifique a responsabilidade pela realização de testes manuais. 

   1.  Aplique recursos de teste automatizados a casos de teste específicos que façam sentido para automação, como casos repetíveis ou executados com frequência, aqueles que exigem tarefas repetitivas ou aqueles que são necessários em várias configurações. 

   1.  Defina scripts de automação de testes, bem como os critérios de sucesso na ferramenta de automação, para que a automação contínua do fluxo de trabalho possa ser iniciada quando casos específicos falharem. 

   1.  Defina critérios de falha específicos para a reversão automatizada. 

1.  Priorize a automação de testes para gerar resultados consistentes com o desenvolvimento completo de casos de teste em que a complexidade e a interação humana têm um risco maior de falha. 

1.  Integre as ferramentas automatizadas de teste e reversão no pipeline de CI/CD. 

   1.  Desenvolva critérios claros de sucesso para as alterações. 

   1.  Monitore e observe para detectar esses critérios e reverter automaticamente as alterações quando critérios específicos de reversão forem atendidos. 

1.  Execute diferentes tipos de teste de produção automatizados, como: 

   1.  Teste A/B para mostrar resultados em comparação com a versão atual entre dois grupos de teste de usuários. 

   1.  Teste canário, que permite implantar a alteração em um subconjunto de usuários antes de lançá-la para todos. 

   1.  Teste de sinalização de atributos, que permite que a sinalização de um único atributo da nova versão seja ativada e desativada de fora da aplicação para que cada novo atributo possa ser validado individualmente. 

   1.  Teste de regressão para verificar novas funcionalidades com componentes inter-relacionados existentes. 

1.  Monitore os aspectos operacionais da aplicação, das transações e das interações com outras aplicações e componentes. Desenvolva relatórios para mostrar o sucesso das alterações por workload e identificar quais partes da automação e do fluxo de trabalho podem ser ainda mais otimizadas. 

   1.  Desenvolva relatórios de resultados de testes que ajudem você a tomar decisões rápidas sobre se os procedimentos de reversão devem ou não ser invocados. 

   1.  Implemente uma estratégia que permita a reversão automatizada com base em condições de falha predefinidas que resultam de um ou mais de seus métodos de teste. 

1.  Desenvolva seus casos de teste automatizados para permitir a reutilização em futuras alterações repetíveis. 

 **Nível de esforço do plano de implementação:** médio 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS06-BP01 Preparar-se para alterações malsucedidas](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) 
+  [OPS06-BP02 Testar as implantações](ops_mit_deploy_risks_test_val_chg.md) 

 **Documentos relacionados:** 
+ [AWS Builders Library \$1 Ensuring rollback safety during deployments ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+  [Redeploy and rollback a deployment with AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html) 
+ [ 8 best practices when automating your deployments with AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)

 **Exemplos relacionados:** 
+ [ Serverless UI testing using Selenium, AWS Lambda, AWS Fargate, and AWS Developer Tools ](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)

 **Vídeos relacionados:** 
+ [ re:Invent 2020 \$1 Sem intervenção manual: como automatizar os pipelines de entrega contínua na Amazon ](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [ re:Invent 2019 \$1 A abordagem da Amazon para implantação de alta disponibilidade ](https://www.youtube.com/watch?v=bCgD2bX1LI4)

# OPERAÇÕES 7. Como saber se está pronto para oferecer suporte a uma workload?
<a name="ops-07"></a>

 Avalie a prontidão operacional de sua carga de trabalho, processos/procedimentos e pessoal para entender os riscos operacionais relacionados. 

**Topics**
+ [OPS07-BP01 Garantir a capacidade da equipe](ops_ready_to_support_personnel_capability.md)
+ [OPS07-BP02 Garantir uma análise consistente da prontidão operacional](ops_ready_to_support_const_orr.md)
+ [OPS07-BP03 Usar runbooks para realizar procedimentos](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 Usar manuais para investigar problemas](ops_ready_to_support_use_playbooks.md)
+ [OPS07-BP05 Tomar decisões embasadas para implantar sistemas e alterações](ops_ready_to_support_informed_deploy_decisions.md)
+ [OPS07-BP06 Viabilizar planos de suporte para workloads de produção](ops_ready_to_support_enable_support_plans.md)

# OPS07-BP01 Garantir a capacidade da equipe
<a name="ops_ready_to_support_personnel_capability"></a>

Tenha um mecanismo para validar que você tem o número adequado de funcionários treinados para fornecer suporte à workload. Eles devem ter treinamento para a plataforma e os serviços que compõem sua workload. Forneça a eles o conhecimento necessário para operar a workload. É necessário ter o número suficiente de funcionários treinados para fornecer suporte à operação da workload e solucionar os incidentes que ocorrerem. Tenha funcionários suficientes para que seja possível alterná-los durante plantões e férias, a fim de evitar a exaustão. 

 **Resultado desejado:** 
+  Há um número suficiente de funcionários treinados para fornecer suporte à workload quando a workload estiver disponível. 
+  Você fornece treinamento para seus funcionários sobre software e serviços que compõem a workload. 

 **Antipadrões comuns:** 
+ Implantar uma workload sem membros da equipe treinados para operar a plataforma e os serviços em uso. 
+  Não ter funcionários suficientes para fornecer suporte à alternâncias de plantão ou folga de funcionários. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Ter membros da equipe qualificados possibilita o suporte eficaz da sua carga de trabalho. 
+  Com um número suficiente de membros na equipe, é possível dar conta da workload e das alternâncias de plantão, reduzindo o risco de exaustão. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Valide se há um número suficiente de funcionários treinados para fornecer suporte à workload. Verifique se você tem membros da equipe suficientes para cobrir as atividades operacionais normais, incluindo alternâncias de plantão. 

 **Exemplo de clientes** 

 A Loja UmaEmpresa garante que as equipes que fornecem suporte à workload estejam completas e treinadas. Há engenheiros suficientes para fornecer suporte a uma alternância de plantão. Os funcionários têm treinamento referente ao software e à plataforma na qual a workload é criada e são incentivados a obter certificações. Há funcionários suficientes para que as pessoas possam tirar folgas enquanto mantêm o suporte à workload e à alternância de plantões. 

 **Etapas da implementação** 

1.  Atribua um número adequado de funcionários para operar e fornecer suporte à workload, incluindo tarefas de plantão. 

1.  Treine seus funcionários referente ao software e às plataformas que compõem a workload. 

   1.  O [AWS Training and Certification](https://aws.amazon.com/training/) tem uma biblioteca de cursos sobre a AWS. Estão disponíveis cursos pagos e gratuitos, online e presenciais. 

   1.  [A AWS promove eventos e webinars](https://aws.amazon.com/events/) por meio dos quais você aprende com especialistas da AWS. 

1.  Avalie regularmente o tamanho e as habilidades da equipe à medida que as condições operacionais e a workload mudam. Ajuste o tamanho e as habilidades da equipe para corresponderem aos requisitos operacionais. 

 **Nível de esforço do plano de implementação:** alto. Contratar e treinar uma equipe para fornecer suporte a uma workload pode exigir um esforço significativo, mas traz benefícios substanciais de longo prazo. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS11-BP04 Realizar o gerenciamento de conhecimento](ops_evolve_ops_knowledge_management.md) – Os membros da equipe devem ter as informações necessárias para operar e fornecer suporte à workload. O gerenciamento de conhecimento é fundamental para fornecer isso. 

 **Documentos relacionados:** 
+  [Eventos e webinars da AWS](https://aws.amazon.com/events/) 
+  [AWS Training and Certification](https://aws.amazon.com/training/) 

# OPS07-BP02 Garantir uma análise consistente da prontidão operacional
<a name="ops_ready_to_support_const_orr"></a>

Use Análises de prontidão operacional (ORRs) para validar que você pode operar sua workload. A ORR é um mecanismo desenvolvido na Amazon para validar que as equipes podem operar as workloads com segurança. Uma ORR é um processo de análise e inspeção que usa uma lista de verificação de requisitos. Uma ORR é uma experiência de autoatendimento que as equipes usam para certificar suas workloads. As ORRs incluem práticas recomendadas de lições aprendidas de nossos anos de experiência na criação de software. 

 Uma lista de verificação de ORR é composta de recomendações de arquitetura, processo operacional, gerenciamento de evento e qualidade de lançamento. Nosso processo de Correção de erros (CoE) é um motivador principal desses itens. Sua própria análise pós-incidente deve impulsionar a evolução de sua própria ORR. Uma ORR não é apenas sobre seguir as práticas recomendadas, mas evitar a recorrência de eventos que você já viu. Por fim, os requisitos de segurança, governança e conformidade também podem ser incluídos em uma ORR. 

 Execute ORRs antes do lançamento de uma workload para disponibilidade geral e por todo o ciclo de vida de desenvolvimento do software. A execução da ORR antes do lançamento aumenta a capacidade de operar a workload com segurança. Execute a ORR periodicamente na workload para identificar qualquer desvio das práticas recomendadas. Você pode ter listas de verificação da ORR para o lançamento de outros serviços e ORRs para avaliações periódicas. Isso ajuda a manter você atualizado sobre as novas práticas recomendadas que surgem e incorporar as lições aprendidas da análise pós-incidente. À medida que seu uso da nuvem amadurece, é possível criar requisitos de ORR em sua arquitetura como padrões. 

 **Resultado desejado:**  você tem uma lista de verificação da ORR com as práticas recomendadas para sua organização. As ORRs são realizadas antes do lançamento das workloads. As ORRs são executadas periodicamente ao longo do ciclo de vida da workload. 

 **Antipadrões comuns:** 
+ Você lança uma workload sem saber se pode operá-la. 
+ Os requisitos de governança e segurança não estão incluídos na certificação de uma workload para o lançamento. 
+ As workloads não são reavaliadas periodicamente. 
+ As workloads são lançadas sem a aplicação dos procedimentos exigidos. 
+ Você vê a repetição das mesmas falhas da causa raiz em várias workloads. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  suas workloads incluem práticas recomendadas de arquitetura, processo e gerenciamento. 
+  As lições aprendidas são incorporadas em seu processo de ORR. 
+  Os procedimentos exigidos estão em vigor no lançamento das workloads. 
+  As ORRs são executadas durante todo o ciclo de vida do software das workloads. 

 **Nível de risco caso essa prática recomendada não seja estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Uma ORR é composta por dois elementos: um processo e uma lista de verificação. O processo da ORR deve ser adotado pela organização e ter o apoio de um patrocinador executivo. No mínimo, as ORRs devem ser realizadas antes do lançamento da workload para disponibilidade geral. Execute a ORR ao longo de todo o ciclo de vida de desenvolvimento do software para mantê-la atualizada com as práticas recomendadas ou os novos requisitos. A lista de verificação da ORR deve incluir itens de configuração, requisitos de segurança e governança e práticas recomendadas de sua organização. Ao longo do tempo, você pode usar serviços como o [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html), o [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)e o [AWS Control Tower Guardrails](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html), para criar práticas recomendadas com base na ORR visando as barreiras de proteção para detecção automáticas das práticas recomendadas. 

 **Exemplo de cliente** 

 Depois de vários incidentes na produção, a Loja UmaEmpresa decidiu implementar um processo de ORR. Ela criou uma lista de verificação composta de práticas recomendadas, requisitos de governança e conformidade e lições aprendidas de interrupções. Novas workloads passam pelo processo de ORR antes do lançamento. É realizada uma ORR anualmente para cada workload com um subconjunto de práticas recomendadas a incorporar novas práticas recomendadas e requisitos que são adicionados à lista de verificação da ORR. Ao longo do tempo, a Loja UmaEmpresa usou o [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) para detectar algumas práticas recomendadas, acelerando o processo de ORR. 

 **Etapas da implementação** 

 Para saber mais sobre as ORRs, leia o [whitepaper de Análises de prontidão operacional (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html). Ele fornece informações detalhadas sobre o histórico do processo de ORR, como criar sua própria prática de ORR e como desenvolver sua lista de verificação da ORR. As etapas a seguir são uma versão resumida desse documento. Para uma compreensão aprofundada do que são as ORRs e de como criar sua própria, recomendamos a leitura desse whitepaper. 

1. Reúna as principais partes interessadas, incluindo os representantes de segurança, operações e desenvolvimento. 

1. Peça para cada parte interessada fornecer pelo menos um requisito. Para a primeira iteração, tente limitar o número de itens para trinta ou menos. 
   +  [Apêndice B: os exemplos de perguntas da ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) do whitepaper de Análises de prontidão operacional (ORR) contém exemplos de perguntas que você pode usar para começar. 

1. Reúna seus requisitos em uma planilha. 
   + Você pode usar o [Custom Lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) no [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) para desenvolver sua ORR e compartilhá-la em suas contas e no AWS Organization. 

1. Identifique uma workload na qual realizar a ORR. O ideal seria em uma workload em pré-lançamento ou uma workload interna. 

1. Execute a lista de verificação completa da ORR e anote as descobertas feitas. As descobertas podem não ser corretas caso esteja ocorrendo uma mitigação. Para descobertas que não tenham uma mitigação, acrescente-as à sua lista de pendências e implemente-as antes do lançamento. 

1. Continue a adicionar práticas recomendadas e requisitos à sua lista de verificação de ORR ao longo do tempo. 

 Os clientes do Suporte com Enterprise Support podem solicitar o [workshop de Análises de prontidão operacional](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) com seu gerente de conta técnico. O workshop é uma sessão interativa de *trabalho em retrospecto* para que você consiga desenvolver sua própria lista de verificação de ORR. 

 **Nível de esforço do plano de implementação:** alto. Adotar uma prática de ORR em sua organização exige a adesão de um patrocinador executivo e das partes interessadas. Crie e atualize a lista de verificação com as opiniões de toda a sua organização. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [OPS01-BP03 Avaliar os requisitos de governança](ops_priorities_governance_reqs.md) – Os requisitos de governança são uma opção natural para uma lista de verificação da ORR. 
+ [OPS01-BP04 Avaliar os requisitos de conformidade](ops_priorities_compliance_reqs.md) – Os requisitos de conformidade, às vezes são incluídos em uma lista de verificação de ORR. Outras vezes, eles constituem um processo separado. 
+ [OPS03-BP07 Fornecer recursos adequados às equipes](ops_org_culture_team_res_appro.md) – A capacidade da equipe é uma boa candidata para um requisito de ORR. 
+ [OPS06-BP01 Preparar-se para alterações malsucedidas](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – Um plano de reversão ou avanço deve ser estabelecido antes do lançamento da workload. 
+ [OPS07-BP01 Garantir a capacidade da equipe](ops_ready_to_support_personnel_capability.md) – Para comportar uma workload, você deve ter o pessoal necessário. 
+ [SEC01-BP03 Identificar e validar objetivos de controle](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – Os objetivos de controle de segurança compõem excelentes requisitos de ORR. 
+ [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) – Os planos de recuperação de desastres são um ótimo requisito de ORR. 
+ [COST02-BP01 Desenvolver políticas com base nos requisitos da sua organização](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) – As políticas de gerenciamento de custos são ótimas para incluir em sua lista de verificação de ORR. 

 **Documentos relacionados:** 
+  [AWS Control Tower - Guardrails in AWS Control Tower (AWS Control Tower: barreiras de proteção no AWS Control Tower)](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 
+  [AWS Well-Architected Tool - Custom Lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) 
+  [Operational Readiness Review Template by Adrian Hornsby (Modelo de Análise de prontidão operacional, por Adrian Hornsby)](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79) 
+  [Whitepaper de Análises de prontidão operacional (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 

 **Vídeos relacionados:** 
+  [AWS Supports You \$1 Building an Effective Operational Readiness Review (ORR) (Apoio do AWS Support: criação de uma Análise de prontidão operacional (ORR) eficaz)](https://www.youtube.com/watch?v=Keo6zWMQqS8) 

 **Exemplos relacionados:** 
+  [Sample Operational Readiness Review (ORR) Lens (Exemplo da perspectiva da Análise de prontidão operacional (ORR))](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens) 

 **Serviços relacionados:** 
+  [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 
+  [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 
+  [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html) 

# OPS07-BP03 Usar runbooks para realizar procedimentos
<a name="ops_ready_to_support_use_runbooks"></a>

 A *runbook* é um processo documentado para alcançar um resultado específico. Runbooks consistem em uma série de etapas que alguém segue para realizar alguma coisa. Runbooks são usados em operações desde os primórdios da aviação. Nas operações na nuvem, usamos runbooks para reduzir o risco e alcançar os resultados desejados. Em essência, um runbook é uma lista de verificação para concluir uma tarefa. 

 Runbooks são fundamentais para a operação de uma workload. Da integração de um novo membro da equipe à implantação de um lançamento importante, os runbooks são os processos codificados que fornecem resultados consistentes independentemente de que os usa. Os runbooks devem estar publicados em um local central e devem ser atualizados à medida que o processo evolui, uma vez que a atualização dos runbooks é um aspecto fundamental de um processo de gerenciamento de mudanças. Também devem incluir orientação sobre tratamento de erros, ferramentas, permissões, exceções e encaminhamentos em caso de problema. 

 À medida que sua organização amadurece, comece a automatizar os runbooks. Comece com runbooks que sejam curtos e usados com frequência. Use linguagens de scripts para automatizar as etapas ou facilitar a realização delas. À medida que você automatiza os primeiros runbooks, vai dedicar tempo à automação de runbooks mais complexos. Com o tempo, a maioria dos seus runbooks deverão ter algum nível de automação. 

 **Resultado desejado:** sua equipe tem um conjunto de guias detalhados para realizar tarefas de workload. Os runbooks contêm o resultado desejado, as ferramentas e permissões necessárias e as instruções para tratamento de erros. Eles estão armazenados em um local central e são atualizados frequentemente. 

 **Antipadrões comuns:** 
+  Depender da memória para concluir cada etapa de um processo. 
+  Implantar mudanças manualmente sem uma lista de verificação. 
+  Vários membros da equipe realizando o mesmo processo, mas com etapas ou resultados diferentes. 
+  Deixar que os runbooks fiquem desatualizados em relação às mudanças no sistema e à automação. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Redução das taxas de erros em tarefas manuais. 
+  Operações realizadas de maneira consistente. 
+  Novos membros da equipe podem começar a realizar tarefas mais cedo. 
+  Os runbooks podem ser automatizados para reduzir o esforço. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Os runbooks podem assumir diversos formatos dependendo do nível de maturidade da sua organização. No mínimo, devem consistir em um documento de texto detalhado. O resultado desejado deve estar claramente identificado. Documentar claramente as permissões ou ferramentas especiais necessárias. Fornecer orientação detalhada sobre tratamento de erros e encaminhamentos em caso de problema. Listar o proprietário do runbook e publicá-lo em um local central. Depois que o runbook estiver documentado, valide-o pedindo que outro membro da equipe o execute. À medida que os procedimentos evoluem, atualize os runbooks de acordo com seu processo de gerenciamento de mudanças. 

 Os runbooks em texto devem ser automatizados à medida que a organização amadurece. Usando serviços como as [automações do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), você pode transformar texto plano em automações que podem ser executadas na workload. Essas automações podem ser executadas em resposta a eventos, reduzindo a sobrecarga operacional de manutenção da workload. 

 **Exemplo de cliente** 

 A AnyCompany Retail precisa realizar atualizações no esquema de banco de dados durante implantações de software. A equipe de operações na nuvem trabalhou com a equipe de administração do banco de dados para criar um runbook para implantação manual dessas mudanças. O runbook lista cada etapa do processo em um formato de lista de verificação. Ele inclui uma seção sobre tratamento de erros em caso de problema. Eles publicaram o runbook na wiki interna junto com outros runbooks. A equipe de operações na nuvem planeja automatizar o runbook em um sprint futuro. 

## Etapas da implementação
<a name="implementation-steps"></a>

 Se você não tem um repositório de documentos, um repositório de controle de versão é um ótimo lugar para começar a criar sua biblioteca de runbooks. Você pode criar runbooks usando Markdown. Disponibilizamos um modelo de runbook que você pode usar para começar a criar runbooks. 

```
# Título do runbook ## Informações do runbook | ID do runbook | Descrição | Ferramentas usadas | Permissões especiais | Criador do runbook | Última atualização | Contato para encaminhamento | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | Para que serve este runbook? Qual é o resultado desejado? | Ferramentas | Permissões | Seu nome | 21-09-2022 | Nome para encaminhamento | ## Etapas 1. Primeira etapa 2. Segunda etapa
```

1.  Se você não tiver um repositório de documentação ou uma wiki, crie um repositório de controle de versão em seu sistema de controle de versão. 

1.  Identifique um processo que não tenha um runbook. Um processo ideal é um que seja realizado quase regularmente, que tenha poucas etapas e que tenha falhas de baixo impacto. 

1.  No repositório de documentos, crie um rascunho de documento em Markdown usando o modelo. Preencha `Título do runbook` e os campos necessários em `Informações do runbook`. 

1.  Começando pela primeira etapa, preencha a seção `Etapas` do runbook. 

1.  Dê o runbook a um membro da equipe. Peça que o use para validar as etapas. Se algo estiver faltando ou não estiver claro, atualize o runbook. 

1.  Disponibilize o runbook em seu armazenamento interno de documentos. Depois, informe a sua equipe e outras partes interessadas. 

1.  Com o passar do tempo, você terá uma biblioteca de runbooks. À medida que essa biblioteca cresce, comece a trabalhar na automatização dos runbooks. 

 **Nível de esforço do plano de implementação:** baixo. O padrão mínimo para um runbook é um guia de texto detalhado. A automatização dos runbooks pode aumentar o esforço de implementação. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md): os runbooks devem ter um proprietário responsável por mantê-los. 
+  [OPS07-BP04 Usar manuais para investigar problemas](ops_ready_to_support_use_playbooks.md): os runbooks e playbooks são semelhantes, com uma diferença importante: um runbook tem um resultado desejado. Em muitos casos, os runbooks são acionados depois que um playbook identifica uma causa raiz. 
+  [OPS10-BP01 Usar um processo para gerenciamento de eventos, incidentes e problemas](ops_event_response_event_incident_problem_process.md): os runbooks fazem parte de uma boa prática de gerenciamento de eventos, incidentes e problemas. 
+  [OPS10-BP02 Ter um processo por alerta](ops_event_response_process_per_alert.md): os runbooks e playbooks devem ser usados para responder a alertas. Com o tempo, essas reações devem ser automatizadas. 
+  [OPS11-BP04 Realizar o gerenciamento de conhecimento](ops_evolve_ops_knowledge_management.md): a manutenção dos runbooks é essencial para o gerenciamento de conhecimento. 

 **Documentos relacionados:** 
+ [Como alcançar excelência operacional usando playbooks e runbooks automatizados](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/) 
+ [AWS Systems Manager: trabalhar com runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 
+ [Playbook para grandes migrações da AWS - Tarefa 4: Como melhorar runbooks de migração](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html) 
+ [Como usar runbooks do AWS Systems Manager Automation para resolver tarefas operacionais](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1) (Guia DIY para runbooks, relatórios de incidentes e resposta a incidentes)](https://www.youtube.com/watch?v=E1NaYN_fJUo) 
+  [How to automate IT Operations on AWS \$1 Amazon Web Services (Como automatizar operações de TI na AWS \$1 Amazon Web Services)](https://www.youtube.com/watch?v=GuWj_mlyTug) 
+  [Integrate Scripts into AWS Systems Manager (Integração de scripts no AWS Systems Manager)](https://www.youtube.com/watch?v=Seh1RbnF-uE) 

 **Exemplos relacionados:** 
+  [AWS Systems Manager: demonstrações de automação](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html) 
+  [AWS Systems Manager: runbook para restaurar um volume raiz usando o snapshot mais recente](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+  [Criar um runbook de resposta a incidentes da AWS usando cadernos Jupyter e CloudTrail Lake](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US) 
+  [Gitlab: runbooks](https://gitlab.com/gitlab-com/runbooks) 
+  [Rubix: uma biblioteca de Python para criação de runbooks em cadernos Jupyter](https://github.com/Nurtch/rubix) 
+  [Como usar o gerador de documentos para criar um runbook personalizado](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html) 
+  [Well-Architected Labs: automatização de operações com playbooks e runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

 **Serviços relacionados:** 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 

# OPS07-BP04 Usar manuais para investigar problemas
<a name="ops_ready_to_support_use_playbooks"></a>

 Os manuais são guias detalhados usados para investigar incidentes. Quando incidentes ocorrem, os manuais são usados para investigar, definir o escopo do impacto e identificar a causa raiz. Os manuais são usados em diversos cenários, desde falhas em implantações até incidentes de segurança. Em muitos casos, os manuais identificam a causa raiz mitigada por um runbook. Os manuais são essenciais aos planos de resposta a incidentes de sua organização. 

 Um bom manual abrange vários aspectos principais. Ele guia o usuário, detalhadamente, ao longo do processo de descoberta. Considerando várias perspectivas, quais etapas devem ser seguidas para diagnosticar um incidente? Defina claramente no manual se são necessárias ferramentas especiais ou permissões elevadas. Ter um plano de comunicação para atualizar as partes interessadas sobre o status da investigação é essencial. Em situações em que a causa raiz ainda não foi identificada, o manual deve ter um plano de escalação. Se a causa raiz tiver sido identificada, o manual deverá indicar um runbook que descreva como resolvê-la. Os manuais devem ser armazenados em um local central e atualizados com frequência. Caso os manuais sejam usados para alertas específicos, forneça às equipes indicadores para o manual no alerta. 

 À medida que sua organização for amadurecendo, automatize seus manuais. Comece com manuais que abordem incidentes de baixo risco. Use scripts para automatizar as etapas de descoberta. Tenha runbooks complementares para mitigar as causas raízes comuns. 

 **Resultado desejado:** Sua organização tem manuais para incidentes comuns. Os manuais são armazenados em um local central e estão disponíveis para os membros da equipe. Os manuais são atualizados com frequência. São criados runbooks complementares para todas as causas raízes conhecidas. 

 **Antipadrões comuns:** 
+  Não há uma maneira padrão de investigar um incidente. 
+  Os membros da equipe precisam confiar na própria memória ou no conhecimento institucional para solucionar uma falha na implantação. 
+  Os novos membros da equipe aprendem a investigar os problemas por meio de tentativa e erro. 
+  As práticas recomendadas para a investigação dos problemas não são compartilhadas entre as equipes. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Os manuais impulsionam seus esforços para mitigar os incidentes. 
+  Diferentes membros da equipe podem usar o mesmo manual para identificar uma causa raiz de maneira consistente. 
+  As causas raízes conhecidas podem ter runbooks desenvolvidos para elas, o que acelera o tempo de recuperação. 
+  Os manuais permitem que os membros da equipe comecem a contribuir o quanto antes. 
+  As equipes podem escalar seus processos com manuais repetíveis. 

 **Nível de risco exposto se essa prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A maneira que você cria e usa os manuais depende da maturidade de sua organização. Se você é iniciante na nuvem, crie manuais no formato de texto em um repositório central de documentos. À medida que sua organização amadurecer, os manuais poderão passar a ser semiautomatizados com linguagens de script, como Python. Esses scripts podem ser executados em um caderno Jupyter para acelerar a descoberta. As organizações avançadas têm manuais totalmente automatizados para problemas comuns que são corrigidos automaticamente com runbooks. 

 Comece a criar seus manuais listando incidentes comuns que ocorrem com sua workload. Para começar, escolha manuais para incidentes com baixo risco e nos quais a causa raiz tenha sido restrita a poucos problemas. Quando você tiver manuais para os cenários mais simples, passe para cenários de alto risco ou cenários em que a causa raiz não seja bem conhecida. 

 Seus manuais em texto deverão ser automatizados à medida que sua organização amadurecer. Usando serviços, como o [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), um texto sem formatação pode ser transformado em automações. Essas automações podem ser executadas em sua workload para acelerar as investigações. Elas podem ser ativadas em resposta a eventos, o que reduz o tempo necessário para descobrir e resolver incidentes. 

 Os clientes podem usar o [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) para responder a incidentes. Esse serviço fornece uma interface única para fazer a triagem de incidentes, informar as partes interessas durante a descoberta e a mitigação e colaborar durante todo o incidente. Ele usa o AWS Systems Manager Automations para acelerar a detecção e a recuperação. 

 **Exemplo de cliente** 

 Um incidente na produção afetou a Loja UmaEmpresa. O engenheiro de plantão usou um manual para investigar o problema. À medida que foi avançando pelas etapas, ele manteve atualizadas as principais partes interessadas, identificadas no manual. O engenheiro identificou a causa raiz como uma condição de corrida em um serviço de back-end. Usando um runbook, o engenheiro reiniciou o serviço, colocando a Loja UmaEmpresa online novamente. 

## Etapas da implementação
<a name="implementation-steps"></a>

 Se você não tem um repositório de documentos, sugerimos criar um repositório de controle de versão para a biblioteca do manual. É possível criar os manuais usando o Markdown, que é compatível com a maioria dos sistemas de automação de manuais. Se você estiver iniciando do zero, use o modelo de exemplo de manual a seguir. 

```
# Título do manual ## Informações do manual | ID do manual | Descrição | Ferramentas usadas | Permissões especiais | Autor do manual | Última atualização | Ponto de contato de escalação | Partes interessadas | Plano de comunicação | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | Para que é este manual? Ele é usado para qual incidente? | Ferramentas | Permissões | Seu nome | 21/9/2022 | Nome para escalação | Nome da parte interessada | Como as atualizações serão comunicadas durante a investigação? | ## Etapas 1. Etapa um 2. Etapa dois
```

1.  Se você não tiver um repositório de documentos ou uma wiki, crie um repositório de controle de versão para seus manuais no sistema de controle de versão. 

1.  Identifique um problema comum que requer investigação. Ele deve ser um cenário em que a causa raiz esteja limitada a poucos problemas e a resolução seja de baixo risco. 

1.  Usando o modelo do Markdown, preencha a seção `Nome do manual` e os campos em `Informações do manual`. 

1.  Preencha as etapas de resolução de problemas. Seja o mais claro possível sobre quais ações devem ser executadas ou quais áreas devem ser investigadas. 

1.  Dê o manual a um membro da equipe e peça para essa pessoa analisá-lo a fim de validá-lo. Caso algo esteja faltando ou não esteja claro, atualize o manual. 

1.  Publique o manual no repositório de documentos e informe sua equipe e as partes interessadas. 

1.  Essa biblioteca de manuais crescerá à medida que você adicionar outros manuais. Quando você tiver vários manuais, comece a automatizá-los usando ferramentas como o AWS Systems Manager Automations a fim de manter a automação e os manuais sincronizados. 

 **Nível de esforço do plano de implementação:** Baixo. Os manuais devem ser documentos de texto armazenados em um local central. Organizações mais consolidadas passarão a automatizar os respectivos manuais. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md): os manuais devem ter um proprietário responsável por mantê-los. 
+  [OPS07-BP03 Usar runbooks para realizar procedimentos](ops_ready_to_support_use_runbooks.md): os runbooks e os manuais são semelhantes, com uma diferença importante: um runbook tem um resultado desejado. Em muitos casos, os runbooks são usados quando um manual identifica uma causa raiz. 
+  [OPS10-BP01 Usar um processo para gerenciamento de eventos, incidentes e problemas](ops_event_response_event_incident_problem_process.md): os manuais fazem parte de uma boa prática de gerenciamento de eventos, incidentes e problemas. 
+  [OPS10-BP02 Ter um processo por alerta](ops_event_response_process_per_alert.md): os runbooks e manuais devem ser usados para responder a alertas. Com o tempo, essas reações devem ser automatizadas. 
+  [OPS11-BP04 Realizar o gerenciamento de conhecimento](ops_evolve_ops_knowledge_management.md): a manutenção dos manuais é essencial para o gerenciamento de conhecimento. 

 **Documentos relacionados:** 
+ [ Achieving Operational Excellence using automated playbook and runbook (Como alcançar excelência operacional usando manuais e runbooks automatizados) ](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+  [AWS Systems Manager: Working with runbooks ( AWS Systems Manager: trabalho com runbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 
+ [ Use AWS Systems Manager Automation runbooks to resolve operational tasks (Usar runbooks do AWS Systems Manager Automation para resolver tarefas operacionais) ](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)

 **Vídeos relacionados:** 
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1) (Guia DIY para runbooks, relatórios de incidentes e resposta a incidentes) ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS Systems Manager Incident Manager - AWS Virtual Workshops (AWS Systems Manager Incident Manager - workshops virtuais da AWS) ](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [ Integrate Scripts into AWS Systems Manager (Integração de scripts no AWS Systems Manager) ](https://www.youtube.com/watch?v=Seh1RbnF-uE)

 **Exemplos relacionados:** 
+ [AWS Customer Playbook Framework (Framework do manual do cliente daAWS) ](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager: Automation walkthroughs (AWS Systems Manager: demonstrações de automação) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [ Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake (Criar um runbook de resposta a incidentes da AWS usando cadernos Jupyter e o CloudTrail Lake) ](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [ Rubix – A Python library for building runbooks in Jupyter Notebooks (Rubix: uma biblioteca de Python para criação de runbooks em cadernos Jupyter) ](https://github.com/Nurtch/rubix)
+ [ Using Document Builder to create a custom runbook (Como usar o gerador de documentos para criar um runbook personalizado) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [ Well-Architected Labs: Automating operations with Playbooks and Runbooks (Well-Architected Labs: automatização de operações com manuais e runbooks) ](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [ Well-Architected Labs: Incident response playbook with Jupyter (Well-Architected Labs: manual de resposta a incidentes com o Jupyter) ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)

 **Serviços relacionados:** 
+ [AWS Systems Manager Automation ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)

# OPS07-BP05 Tomar decisões embasadas para implantar sistemas e alterações
<a name="ops_ready_to_support_informed_deploy_decisions"></a>

Há processos em vigor para alterações com e sem êxito feitas na workload. Uma estratégia pre-mortem é um exercício em que uma equipe simula uma falha para desenvolver estratégias de mitigação. Use as estratégias pre-mortem para antecipar falhas e criar procedimentos, quando apropriado. Avalie os benefícios e os riscos de implantar alterações na workload. Verifique se todas as alterações estão em conformidade com a governança. 

 **Resultado desejado:** 
+  Você toma decisões embasadas ao implantar alterações na workload. 
+  As alterações estão em conformidade com a governança. 

 **Antipadrões comuns:** 
+ Implantar uma alteração em nossa workload sem um processo para lidar com uma implantação com falha.
+ Fazer alterações no ambiente de produção que estão fora da conformidade com os requisitos de governança.
+ Implantar uma nova versão da workload sem estabelecer uma referência para a utilização de recursos.

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Você está preparado para alterações sem êxito na workload. 
+  As alterações na workload estão em conformidade com as políticas de governança. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Use estratégias pre-mortem no desenvolvimento de processos para alterações sem êxito. Documente os processos de alterações sem êxito. Garanta que todas as alterações estejam em conformidade com a governança. Avalie os benefícios e os riscos de implantar alterações na workload. 

 **Exemplo de clientes** 

 A Loja UmaEmpresa realiza estratégias pre-mortem regularmente para validar seus processos de alterações sem êxito. Os processos são documentados em uma Wiki compartilhada e atualizados regularmente. Todas as alterações estão em conformidade com os requisitos de governança. 

 **Etapas da implementação** 

1.  Tome decisões embasadas ao implantar alterações na workload. Estabeleça e revise os critérios de uma implantação bem-sucedida. Desenvolva cenários ou critérios que acionariam a reversão de uma alteração. Pondere os benefícios de implantar alterações considerando os riscos de uma alteração sem êxito. 

1.  Verifique se todas as alterações estão em conformidade com as políticas de governança. 

1.  Use estratégias pre-mortem para alterações sem êxito e documente as estratégias de migração. Realize um exercício de simulação para modelar uma alteração sem êxito e validar os procedimentos de reversão. 

 **Nível de esforço do plano de implementação:** moderado. Implementar uma prática de estratégias pre-mortem requer coordenação e esforço das partes interessadas na organização. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS01-BP03 Avaliar os requisitos de governança](ops_priorities_governance_reqs.md) – Os requisitos de governança são um fator fundamental para determinar se uma alteração deve ser implementada. 
+  [OPS06-BP01 Preparar-se para alterações malsucedidas](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – Estabeleça planos para mitigar uma implantação sem êxito e use estratégias pre-mortem para validá-los. 
+  [OPS06-BP02 Testar as implantações](ops_mit_deploy_risks_test_val_chg.md) – Toda alteração de software deve ser testada adequadamente antes da implantação para reduzir os defeitos na produção. 
+  [OPS07-BP01 Garantir a capacidade da equipe](ops_ready_to_support_personnel_capability.md) – Ter um número suficiente de funcionários treinados para fornecer suporte à workload é essencial para tomar uma decisão embasada quanto à implantação de uma alteração no sistema. 

 **Documentos relacionados:** 
+ [Amazon Web Services: risco e conformidade](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [Modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [ Governance in the Nuvem AWS: The Right Balance Between Agility and Safety ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)(Governança na Nuvem AWS: o equilíbrio certo entre agilidade e segurança)

# OPS07-BP06 Viabilizar planos de suporte para workloads de produção
<a name="ops_ready_to_support_enable_support_plans"></a>

 Viabilize o suporte para qualquer software e quaisquer serviços dos quais sua workload de produção dependa. Selecione um nível de suporte apropriado para atender às necessidades de nível de serviço da produção. Planos de suporte para essas dependências são necessários no caso de interrupção de um serviço ou de um problema de software. Documente os planos de suporte e como solicitar suporte para todos os fornecedores de serviços e software. Implemente mecanismos que verifiquem se os pontos de contato do suporte são mantidos atualizados. 

 **Resultado desejado:** 
+  Implemente planos de suporte para software e serviços dos quais as workloads de produção dependem. 
+  Escolha um plano de suporte apropriado com base nas necessidades de nível de serviço. 
+  Documente os planos de suporte, os níveis de suporte e como solicitar suporte. 

 **Antipadrões comuns:** 
+  Você não tem nenhum plano de suporte junto a um fornecedor de software essencial. Sua workload é afetada por isso e você não pode fazer nada para agilizar a correção ou obter atualizações em tempo hábil do fornecedor. 
+  Um desenvolvedor que era o principal ponto de contato com um fornecedor de software deixou a empresa. Você não consegue entrar em contato com o suporte do fornecedor diretamente. Você precisa despender tempo pesquisando e navegando por sistemas de contato genéricos, aumentando o tempo requerido para responder quando necessário. 
+  Ocorre uma interrupção na produção relacionada a um fornecedor de software. Não há nenhuma documentação sobre como abrir um caso de suporte. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Com o nível de suporte apropriado, você é capaz de obter uma resposta no espaço de tempo requerido para atender a necessidades de nível de serviço. 
+  Como um cliente com suporte, você pode encaminhar a questão se houver problemas na produção. 
+  Os fornecedores de software e serviços podem ajudar na resolução de problemas durante um incidente. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Viabilize planos de suporte para qualquer software e quaisquer serviços dos quais sua workload de produção dependa. Estabeleça planos de suporte apropriados para atender a necessidades de nível de serviço. Para clientes da AWS, isso significa habilitar o AWS Business Support ou superior em quaisquer contas em que você tenha workloads de produção. Entre em contato regularmente com os fornecedores de suporte para obter atualizações sobre ofertas, processos e contatos de suporte. Documente como solicitar suporte de fornecedores de software e serviços e sobre como encaminhar problemas se houver uma interrupção. Implemente mecanismos para manter os contatos de suporte atualizados. 

 **Exemplo de clientes** 

 Na Loja UmaEmpresa, todas dependências de software e serviços comerciais contam com planos de suporte. Por exemplo, eles têm o AWS Enterprise Support habilitado em todas as contas com workloads de produção. Qualquer desenvolvedor pode abrir um caso de suporte quando há um problema. Há uma página de wiki com informações sobre como solicitar suporte, a quem notificar e as práticas recomendadas para agilizar um caso. 

 **Etapas da implementação** 

1.  Trabalhe com as partes interessadas em sua organização para identificar fornecedores de software e serviços dos quais sua workload dependa. Documente essas dependências. 

1.  Determine as necessidades de nível de serviço para sua workload. Selecione um plano de suporte alinhado a elas. 

1.  Para software e serviços comerciais, estabeleça um plano de suporte com os fornecedores. 

   1.  A assinatura do AWS Business Support ou superior para todas as contas de produção fornece um tempo de resposta rápido do AWS Support e é altamente recomendada. Se você não tiver suporte premium, precisará de um plano de ação para lidar com os problemas, o que requer a ajuda do AWS Support. O AWS Support oferece um conjunto de ferramentas e tecnologia, pessoas e programas projetados para ajudar você de forma proativa a otimizar a performance, reduzir custos e inovar com maior rapidez. O AWS Business Support oferece benefícios adicionais, incluindo acesso ao AWS Trusted Advisor e ao AWS Personal Health Dashboard e tempos de resposta mais rápidos. 

1.  Documente o plano de suporte em sua ferramenta de gerenciamentos de conhecimentos. Inclua como solicitar suporte, a quem notificar se for aberto um caso de suporte e como encaminhar o problema durante um incidente. Uma wiki é um bom mecanismo para possibilitar que todos façam as atualizações necessárias na documentação quando forem informados sobre alterações em processos ou contatos de suporte. 

 **Nível de esforço do plano de implementação:** baixo. A maioria dos fornecedores de software e serviços oferece planos de suporte que requerem adesão. Documentar e compartilhar práticas recomendadas no sistema de gerenciamento de conhecimentos garante que sua equipe saiba o que fazer quando houver um problema na produção. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md) 

 **Documentos relacionados:** 
+ [AWS Support Plans ](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)

 **Serviços relacionados:** 
+ [AWS Business Support ](https://aws.amazon.com/premiumsupport/plans/business/)
+ [AWS Enterprise Support ](https://aws.amazon.com/premiumsupport/plans/enterprise/)

# Operar
<a name="a-operate"></a>

**Topics**
+ [OPERAÇÕES 8. Como utilizar a observabilidade da workload em sua organização?](ops-08.md)
+ [OPERAÇÕES 9. Como compreender a integridade de suas operações?](ops-09.md)
+ [OPERAÇÕES 10. Como gerenciar os eventos de workload e operações?](ops-10.md)

# OPERAÇÕES 8. Como utilizar a observabilidade da workload em sua organização?
<a name="ops-08"></a>

Garanta a integridade ideal da workload usando a observabilidade. Utilize métricas, logs e rastreamentos relevantes para obter uma visão abrangente do desempenho de sua workload e resolver problemas com eficiência.

**Topics**
+ [OPS08-BP01 Analisar métricas de workload](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 Analisar logs de workloads](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 Analisar rastreamentos de workload](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 Criar alertas acionáveis](ops_workload_observability_create_alerts.md)
+ [OPS08-BP05 Criar painéis](ops_workload_observability_create_dashboards.md)

# OPS08-BP01 Analisar métricas de workload
<a name="ops_workload_observability_analyze_workload_metrics"></a>

 Depois de implementar a telemetria de aplicações, analise regularmente as métricas coletadas. Embora a latência, as solicitações, os erros e a capacidade (ou cotas) forneçam informações sobre o desempenho do sistema, é fundamental priorizar a análise das métricas de resultados comerciais. Isso garante que você esteja tomando decisões orientadas por dados alinhadas aos seus objetivos de negócios. 

 **Resultado desejado:** Insights precisos sobre o desempenho da workload que impulsionam decisões baseadas em dados, garantindo o alinhamento com os objetivos de negócios. 

 **Antipadrões comuns:** 
+  Análise das métricas isoladamente, sem considerar seu impacto nos resultados comerciais. 
+  Confiança excessiva em métricas técnicas e, ao mesmo tempo, marginalização das métricas de negócios. 
+  Revisão pouco frequente das métricas, perdendo oportunidades de tomada de decisão em tempo real. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Compreensão aprimorada da correlação entre desempenho técnico e resultados comerciais. 
+  Processo de tomada de decisão aprimorado baseado em dados em tempo real. 
+  Identificação proativa e mitigação de problemas antes que eles afetem os resultados comerciais. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Utilize ferramentas como o Amazon CloudWatch para realizar análises métricas. Serviços da AWS como o AWS Cost Anomaly Detection e o Amazon DevOps Guru podem ser usados para detectar anomalias, especialmente quando os limites estáticos são desconhecidos ou quando os padrões de comportamento são mais adequados para a detecção de anomalias. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  **Analise e revise:** Analise e interprete regularmente suas métricas de workload. 

   1.  Priorize as métricas de resultados comerciais em vez das métricas puramente técnicas. 

   1.  Entenda a importância de picos, quedas ou padrões em seus dados. 

1.  **Use o Amazon CloudWatch:** Use o Amazon CloudWatch para uma visão centralizada e uma análise aprofundada. 

   1.  Configure painéis do CloudWatch para visualizar suas métricas e compará-las ao longo do tempo. 

   1.  Use [percentis no CloudWatch](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/) para obter uma visão clara da distribuição métrica, o que pode ajudar na definição de SLAs e na compreensão de valores discrepantes. 

   1.  Configure o [AWS Cost Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) para identificar padrões incomuns sem depender de limites estáticos. 

   1.  Implemente [a observabilidade entre contas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html) para monitorar e solucionar problemas de aplicações que abrangem várias contas em uma região. 

   1.  Use [insights métricos do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) para consultar e analisar dados métricos em contas e regiões, identificando tendências e anomalias. 

   1.  Aplique [matemática métrica do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) para transformar, agregar ou realizar cálculos em suas métricas para obter insights mais profundos. 

1.  **Empregue o Amazon DevOps Guru:** Incorpore o [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) por sua detecção de anomalias aprimorada por machine learning para identificar sinais precoces de problemas operacionais em suas aplicações sem servidor e corrigi-los antes que afetem seus clientes. 

1.  **Otimize com base em insights: ** Tome decisões informadas com base em sua análise métrica para ajustar e melhorar as workloads. 

 **Nível de esforço do plano de implementação:** Médio 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS04-BP01 Identificar os indicadores-chave de performance](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementar a telemetria de aplicações](ops_observability_application_telemetry.md) 

 **Documentos relacionados:** 
+ [ The Wheel Blog - Emphasizing the importance of continually reviewing metrics (The Wheel Blog: como enfatizar a importância de revisar continuamente as métricas) ](https://aws.amazon.com/blogs/opensource/the-wheel/)
+ [ Percentile are important (O percentil é importante) ](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)
+ [ Using AWS Cost Anomaly Detection (Uso da AWS Cost Anomaly Detection) ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ A observabilidade entre contas do CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)
+ [ Query your metrics with CloudWatch Metrics Insights (Consulte suas métricas com o CloudWatch Metrics Insights) ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)

 **Vídeos relacionados:** 
+ [ Enable Cross-Account Observability in Amazon CloudWatch (Ative a observabilidade entre contas no Amazon CloudWatch) ](https://www.youtube.com/watch?v=lUaDO9dqISc)
+ [ Introduction to Amazon DevOps Guru (Introdução ao Amazon DevOps Guru) ](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [ Continuously Analyze Metrics using AWS Cost Anomaly Detection (Analise continuamente as métricas usando o AWS Cost Anomaly Detection) ](https://www.youtube.com/watch?v=IpQYBuay5OE)

 **Exemplos relacionados:** 
+ [ Um workshop de observabilidade ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Obter insights operacionais com AIOps usando Amazon DevOps Guru ](https://catalog.us-east-1.prod.workshops.aws/workshops/f92df379-6add-4101-8b4b-38b788e1222b/en-US)

# OPS08-BP02 Analisar logs de workloads
<a name="ops_workload_observability_analyze_workload_logs"></a>

 Analisar regularmente os logs da workload é essencial para obter uma compreensão mais profunda dos aspectos operacionais de sua aplicação. Ao filtrar, visualizar e interpretar com eficiência os dados de log, você pode otimizar continuamente o desempenho e a segurança das aplicações. 

 **Resultado desejado:** Informações ricas sobre o comportamento e as operações da aplicação derivadas de uma análise completa de log, garantindo a detecção e mitigação proativas de problemas. 

 **Antipadrões comuns:** 
+ Negligenciar a análise dos logs até que surja um problema crítico.
+ Não usar o conjunto completo de ferramentas disponíveis para análise de logs, perdendo insights essenciais.
+  Confiar exclusivamente na revisão manual dos logs, sem aproveitar os recursos de automação e consulta. 

 **Benefícios de estabelecer esta prática recomendada:** 
+ Identificação proativa de gargalos operacionais, ameaças à segurança e outros possíveis problemas.
+ Utilização eficiente dos dados de log para otimização contínua da aplicação.
+  Compreensão aprimorada do comportamento da aplicação, auxiliando na depuração e solução de problemas. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 [O Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) é uma ferramenta poderosa para análise de logs. Recursos integrados, como o CloudWatch Logs Insights e Contributor Insights, tornam intuitivo e eficiente o processo de derivação de informações significativas dos logs. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  **Configure o CloudWatch Logs:** Configure aplicações e serviços para enviar logs para o CloudWatch Logs. 

1.  **Configure o CloudWatch Logs Insights:** Use o [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) para pesquisar e analisar interativamente seus dados de log. 

   1.  Crie consultas para extrair padrões, visualizar dados de log e obter insights acionáveis. 

1.  **Utilize o Contributor Insights** Use o [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) para identificar os principais locutores em dimensões de alta cardinalidade, como endereços IP ou agentes-usuários. 

1.  **Implemente filtros de métrica do CloudWatch Logs:** configure [os filtros de métrica de log do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) para converter dados de log em métricas acionáveis. Isso permite que você defina alarmes ou analise melhor os padrões. 

1.  **Revisão e refinamento regulares:** Revise periodicamente suas estratégias de análise de log para capturar todas as informações relevantes e otimizar continuamente o desempenho da aplicação. 

 **Nível de esforço do plano de implementação:** Médio. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS04-BP01 Identificar os indicadores-chave de performance](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementar a telemetria de aplicações](ops_observability_application_telemetry.md) 
+  [OPS08-BP01 Analisar métricas de workload](ops_workload_observability_analyze_workload_metrics.md) 

 **Documentos relacionados:** 
+ [ Análise de dados de log com o CloudWatch Logs Insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [ Uso do CloudWatch Contributor Insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)
+ [ Criação e gerenciamento de filtros de métrica de log do CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)

 **Vídeos relacionados:** 
+ [ Analyze Log Data with CloudWatch Logs Insights (Análise de dados de log com o CloudWatch Logs Insights) ](https://www.youtube.com/watch?v=2s2xcwm8QrM)
+ [ Use CloudWatch Contributor Insights to Analyze High-Cardinality Data (Use o CloudWatch Contributor Insights para analisar dados de alta cardinalidade) ](https://www.youtube.com/watch?v=ErWRBLFkjGI)

 **Exemplos relacionados:** 
+ [ Exemplos de consultas do CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [ Um workshop de observabilidade ](https://catalog.workshops.aws/observability/en-US/intro)

# OPS08-BP03 Analisar rastreamentos de workload
<a name="ops_workload_observability_analyze_workload_traces"></a>

 Analisar dados de rastreamento é crucial para obter uma visão abrangente da jornada operacional de uma aplicação. Ao visualizar e compreender as interações entre vários componentes, o desempenho pode ser ajustado, os gargalos identificados e as experiências do usuário aprimoradas. 

 **Resultado desejado:** Obtenha uma visibilidade clara das operações distribuídas da sua aplicação, permitindo uma resolução mais rápida de problemas e uma experiência de usuário aprimorada. 

 **Antipadrões comuns:** 
+  Ignorar dados de rastreamento, confiando apenas em logs e métricas. 
+  Não correlacionar dados de rastreamento com logs associados. 
+  Ignorar as métricas derivadas de rastreamentos, como latência e taxas de falhas. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Aprimoramento da solução de problemas e redução do tempo médio de resolução (MTTR). 
+  Insights sobre dependências e seu impacto. 
+  Identificação e correção rápidas de problemas de desempenho. 
+  Uso de métricas derivadas de rastreamento para uma tomada de decisão informada. 
+  Experiências de usuário aprimoradas por meio de interações otimizadas de componentes. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 [O AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) oferece um pacote abrangente para análise de dados de rastreamento, fornecendo uma visão holística das interações de serviços, monitorando as atividades do usuário e detectando problemas de desempenho. Recursos como ServiceLens, X-Ray Insights, X-Ray Analytics e Amazon DevOps Guru aprimoram a profundidade dos insights acionáveis derivados de dados de rastreamento. 

### Etapas da implementação
<a name="implementation-steps"></a>

 As etapas a seguir oferecem uma abordagem estruturada para implementar com eficácia a análise de dados de rastreamento usando serviços da AWS: 

1.  **Integre o AWS X-Ray:** Integre o X-Ray às suas aplicações para capturar dados de rastreamento. 

1.  **Analise métricas do X-Ray:** Aprofunde-se em métricas derivadas de rastreamentos do X-Ray, como latência, taxas de solicitação, taxas de falhas e distribuições de tempo de resposta usando o [mapa de serviços](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html#xray-console-servicemap-view) para monitorar a integridade da aplicação. 

1.  **Use o ServiceLens:** Use o [mapa do ServiceLens](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_service_map.html) para melhorar a observabilidade de seus serviços e aplicações. Isso permite a visualização integrada de rastreamentos, métricas, logs, alarmes e outras informações de integridade. 

1.  **Habilite o X-Ray Insights:** 

   1.  Ative o [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html) para detecção automática de anomalias em rastreamentos. 

   1.  Examine os insights para identificar padrões e determinar as causas principais, como maiores taxas de falhas ou latências. 

   1.  Consulte o cronograma de insights para uma análise cronológica dos problemas detectados. 

1.  **Use o X-Ray Analytics:** [O X-Ray Analytics](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html) permite que você explore minuciosamente os dados de rastreamento, identifique padrões e extraia insights. 

1.  **Use grupos no X-Ray:** Crie grupos no X-Ray para filtrar rastreamentos com base em critérios como alta latência, permitindo uma análise mais direcionada. 

1.  **Incorpore o Amazon DevOps Guru:** Use o [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) para se beneficiar dos modelos de machine learning que identificam anomalias operacionais nos rastreamentos. 

1.  **Use o CloudWatch Synthetics:** Use o [CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html) para criar canários para monitorar continuamente os endpoints e fluxos de trabalho. Esses canários podem integrar-se com o X-Ray para fornecer dados de rastreamento para uma análise aprofundada das aplicações que estão sendo testadas. 

1.  **Use o Monitoramento de Usuários Reais (RUM):** Com o [AWS X-Ray e o CloudWatch RUM](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-RUM.html), você pode analisar e depurar o caminho da solicitação a partir dos usuários finais de sua aplicação por meio de serviços downstream gerenciados pela AWS . Isso ajuda você a identificar tendências e erros de latência que afetam seus usuários. 

1.  **Correlacionar com logs:** Correlacione [dados de rastreamento com logs relacionados](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_troubleshooting.html#servicelens_troubleshooting_Nologs) dentro da visualização de rastreamento do X-Ray para uma perspectiva granular sobre o comportamento da aplicação. Isso permite que você visualize eventos de log diretamente associados às transações rastreadas. 

 **Nível de esforço do plano de implementação:** Médio. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS08-BP01 Analisar métricas de workload](ops_workload_observability_analyze_workload_metrics.md) 
+  [OPS08-BP02 Analisar logs de workloads](ops_workload_observability_analyze_workload_logs.md) 

 **Documentos relacionados:** 
+ [ Uso do ServiceLens para monitorar a integridade da aplicação ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html)
+ [ Explorar dados de rastreamento com o X-Ray Analytics ](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html)
+ [ Detectar anomalias em rastreamentos com o X-Ray Insights ](https://docs.aws.amazon.com/xray/latest/devguide/xray-insights.html)
+ [ Monitorar continuamente com o CloudWatch Synthetics ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)

 **Vídeos relacionados:** 
+ [ Analyze and Debug Applications Using Amazon CloudWatch Synthetics and AWS X-Ray (Analise e depure aplicações usando Amazon CloudWatch Synthetics e AWS X-Ray) ](https://www.youtube.com/watch?v=s2WvaV2eDO4)
+ [ Use AWS X-Ray Insights (Use o AWS X-Ray Insights) ](https://www.youtube.com/watch?v=tl8OWHl6jxw)

 **Exemplos relacionados:** 
+ [ Um workshop de observabilidade ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Como implementar o X-Ray com o AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html)
+ [ Modelos canário do CloudWatch Synthetics ](https://github.com/aws-samples/cloudwatch-synthetics-canary-terraform)

# OPS08-BP04 Criar alertas acionáveis
<a name="ops_workload_observability_create_alerts"></a>

 Detectar e responder prontamente aos desvios no comportamento da sua aplicação é crucial. É essencial reconhecer quando os resultados com base nos indicadores-chave de performance (KPIs) estão em risco ou quando surgem anomalias inesperadas. Basear alertas em KPIs garante que os sinais que você recebe estejam diretamente vinculados ao impacto comercial ou operacional. Essa abordagem de alertas acionáveis promove respostas proativas e ajuda a manter o desempenho e a confiabilidade do sistema. 

 **Resultado desejado:** Receba alertas oportunos, relevantes e acionáveis para rápida identificação e mitigação de possíveis problemas, especialmente quando os resultados do KPI estão em risco. 

 **Antipadrões comuns:** 
+  A configuração de muitos alertas não críticos leva à fadiga de alertas. 
+  A não priorização de alertas com base em KPIs dificulta a compreensão do impacto comercial dos problemas. 
+  A não abordagem das causas-raiz leva a alertas repetitivos para o mesmo problema. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Redução da fadiga de alertas ao se concentrar em alertas acionáveis e relevantes. 
+  Maior disponibilidade e confiabilidade do sistema por meio da detecção e mitigação proativas de problemas. 
+  Colaboração em equipe aprimorada e resolução mais rápida de problemas por meio da integração com ferramentas populares de alerta e comunicação. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Para criar um mecanismo de alerta eficaz, é fundamental usar métricas, logs e dados de rastreamento que sinalizem quando os resultados com base nos KPIs estão em risco ou quando anomalias são detectadas. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  **Determine indicadores-chave de performance (KPIs):** Identifique os KPIs de sua aplicação. Os alertas devem estar vinculados a esses KPIs para refletir com precisão o impacto nos negócios. 

1.  **Implemente a detecção de anomalias:** 
   +  **Use o AWS Cost Anomaly Detection:** configure o [AWS Cost Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) para detectar automaticamente padrões incomuns, garantindo que os alertas sejam gerados somente para anomalias genuínas. 
   +  **Use o X-Ray Insights:** 

     1.  Configure o [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html) para detectar anomalias nos dados de rastreamento. 

     1.  Configure [notificações no X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications) para ser alertado sobre problemas detectados. 
   +  **Integre com o DevOps Guru:** 

     1.  Utilize o [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) devido a seus recursos de machine learning na detecção de anomalias operacionais com dados existentes. 

     1.  Navegue até as [configurações de notificação](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html#navigate-to-notification-settings) no DevOps Guru para configurar alertas de anomalias. 

1.  **Implemente alertas acionáveis:** Crie alertas que forneçam informações adequadas para ação imediata. 

1.  **Reduza a fadiga de alarmes:** Minimize os alertas não críticos. Equipes sobrecarregadas com vários alertas insignificantes podem não perceber problemas críticos e a eficácia geral do mecanismo de alerta fica diminuída. 

1.  **Configurar alarmes compostos:** Use os [alarmes compostos do Amazon CloudWatch](https://aws.amazon.com/blogs/mt/improve-monitoring-efficiency-using-amazon-cloudwatch-composite-alarms-2/) para consolidar vários alarmes. 

1.  **Integre com ferramentas de alerta:** Incorpore ferramentas como [Ops Genie](https://www.atlassian.com/software/opsgenie) e [PagerDuty](https://www.pagerduty.com/). 

1.  **Utilize o Amazon Q Developer in chat applications** integre o [Amazon Q Developer in chat applications](https://aws.amazon.com/chatbot/)para retransmitir alertas para Chime, Microsoft Teams e Slack. 

1.  **Alerta baseado em logs:** Use o [filtros de métrica de log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) no CloudWatch para criar alarmes com base em eventos de log específicos. 

1.  **Revise e repita:** Revise e revisite regularmente as configurações de alerta. 

 **Nível de esforço do plano de implementação:** Médio. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS04-BP01 Identificar os indicadores-chave de performance](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementar a telemetria de aplicações](ops_observability_application_telemetry.md) 
+  [OPS04-BP03 Implementar a telemetria da experiência do usuário](ops_observability_customer_telemetry.md) 
+  [OPS04-BP04 Implementar a telemetria de dependências](ops_observability_dependency_telemetry.md) 
+  [OPS04-BP05 Implementar rastreamento distribuído](ops_observability_dist_trace.md) 
+  [OPS08-BP01 Analisar métricas de workload](ops_workload_observability_analyze_workload_metrics.md) 
+  [OPS08-BP02 Analisar logs de workloads](ops_workload_observability_analyze_workload_logs.md) 
+  [OPS08-BP03 Analisar rastreamentos de workload](ops_workload_observability_analyze_workload_traces.md) 

 **Documentos relacionados:** 
+ [ Uso dos alarmes do Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [ Crie um alarme composto ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [ Crie um alarme do CloudWatch com base na detecção de anomalias ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)
+ [ Notificações do DevOps Guru ](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html)
+ [ Notificações do X-Ray Insights ](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)
+ [ Monitore, opere e solucione problemas de seus recursos da AWS com ChatOps interativos ](https://aws.amazon.com/chatbot/)
+ [ Guia de integração do Amazon CloudWatch \$1 PagerDuty ](https://support.pagerduty.com/docs/amazon-cloudwatch-integration-guide)
+ [ Integre o OpsGenie com o Amazon CloudWatch ](https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-amazon-cloudwatch/)

 **Vídeos relacionados:** 
+ [ Create Composite Alarms in Amazon CloudWatch (Criar alarmes compostos no Amazon CloudWatch) ](https://www.youtube.com/watch?v=0LMQ-Mu-ZCY)
+ [ Amazon Q Developer in chat applications Overview (Visão geral do Amazon Q Developer in chat applications) ](https://www.youtube.com/watch?v=0jUSEfHbTYk)
+ [AWS on Air ft. Mutative Commands in Amazon Q Developer in chat applications (Comandos mutativos no Amazon Q Developer in chat applications) ](https://www.youtube.com/watch?v=u2pkw2vxrtk)

 **Exemplos relacionados:** 
+ [ Alarmes, gerenciamento de incidentes e remediação na nuvem com o Amazon CloudWatch ](https://aws.amazon.com/blogs/mt/alarms-incident-management-and-remediation-in-the-cloud-with-amazon-cloudwatch/)
+ [ Tutorial: criação de uma regra do Amazon EventBridge que envia notificações para o Amazon Q Developer in chat applications ](https://docs.aws.amazon.com/chatbot/latest/adminguide/create-eventbridge-rule.html)
+ [ Um workshop de observabilidade ](https://catalog.workshops.aws/observability/en-US/intro)

# OPS08-BP05 Criar painéis
<a name="ops_workload_observability_create_dashboards"></a>

 Os painéis são a visão centrada no ser humano dos dados de telemetria de suas workloads. Embora forneçam uma interface visual vital, eles não devem substituir os mecanismos de alerta, mas sim complementá-los. Quando elaborados com cuidado, eles não apenas oferecem insights rápidos sobre a integridade e o desempenho do sistema, como também podem apresentar às partes interessadas informações em tempo real sobre os resultados empresariais e o impacto dos problemas. 

 **Resultado desejado:** Insights claros e acionáveis sobre a integridade do sistema e dos negócios usando representações visuais. 

 **Antipadrões comuns:** 
+  Painéis complicados demais e com muitas métricas. 
+  Confiar em painéis sem alertas para detecção de anomalias. 
+  Não atualizar os painéis à medida que as workloads evoluem. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Visibilidade imediata das métricas e KPIs críticos do sistema. 
+  Comunicação e compreensão aprimoradas com as partes interessadas. 
+  Visão rápida do impacto dos problemas operacionais. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 **Painéis centrados nos negócios** 

 Painéis personalizados para os KPIs de negócios envolvem uma gama maior de partes interessadas. Embora essas pessoas possam não estar interessadas nas métricas do sistema, elas estão interessadas em entender as implicações comerciais desses números. Um painel centrado nos negócios garante que todas as métricas técnicas e operacionais monitoradas e analisadas estejam sincronizadas com as metas empresariais abrangentes. Esse alinhamento fornece clareza, garantindo que todos estejam em sintonia sobre o que é essencial e o que não é. Além disso, painéis que destacam os KPIs de negócios tendem a ser mais acionáveis. As partes interessadas podem entender rapidamente a integridade das operações, as áreas que precisam de atenção e o impacto potencial nos resultados empresariais. 

 Com isso em mente, ao criar seus painéis, garanta que haja um equilíbrio entre métricas técnicas e KPIs comerciais. Ambos são vitais, mas atendem a públicos diferentes. O ideal é que você tenha painéis que forneçam uma visão holística da integridade e do desempenho do sistema e, ao mesmo tempo, enfatizem os principais resultados comerciais e suas implicações. 

 Os painéis do Amazon CloudWatch são páginas iniciais personalizáveis no console do CloudWatch, que você pode usar para monitorar os recursos em uma única visualização, mesmo aqueles distribuídos por Regiões da AWS e contas diferentes. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  **Crie um painel básico:** [crie um novo painel no CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)e dê a ele um nome descritivo. 

1.  **Use widgets de Markdown:** antes de mergulhar nas métricas, use [widgets de Markdown](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_text_dashboard.html) para adicionar contexto textual na parte superior do painel. Isso deve explicar o que o painel abrange, a importância das métricas representadas e também pode conter links para outros painéis e ferramentas de solução de problemas. 

1.  **Crie variáveis do painel:** [incorpore variáveis do painel](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html) quando apropriado, para permitir visualizações dinâmicas e flexíveis do painel. 

1.  **Crie widgets de métricas:** [adicione widgets de métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html) para visualizar várias métricas que sua aplicação emite, adaptando esses widgets para representar com eficácia a integridade do sistema e os resultados empresariais. 

1.  **Consultas do Log Insights:** utilize o [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) para obter métricas acionáveis de seus logs e exibir esses insights em seu painel. 

1.  **Configurar alarmes:** integre [alarmes do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_alarm_dashboard.html) em seu painel para uma visão rápida de qualquer métrica que esteja ultrapassando seus limites. 

1.  **Use o Contributor Insights:** incorpore o [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-ViewReports.html) para analisar campos de alta cardinalidade e obter uma compreensão mais clara dos principais colaboradores do seu recurso. 

1.  **Crie widgets personalizados:** para necessidades específicas não atendidas pelos widgets padrão, considere criar [widgets personalizados](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html). Eles podem ser extraídos de várias fontes de dados ou representar dados de maneiras exclusivas. 

1.  **Repita e refine:** à medida que sua aplicação evolui, revise regularmente seu painel para garantir sua relevância. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS04-BP01 Identificar os indicadores-chave de performance](ops_observability_identify_kpis.md) 
+  [OPS08-BP01 Analisar métricas de workload](ops_workload_observability_analyze_workload_metrics.md) 
+  [OPS08-BP02 Analisar logs de workloads](ops_workload_observability_analyze_workload_logs.md) 
+  [OPS08-BP03 Analisar rastreamentos de workload](ops_workload_observability_analyze_workload_traces.md) 
+  [OPS08-BP04 Criar alertas acionáveis](ops_workload_observability_create_alerts.md) 

 **Documentos relacionados:** 
+ [ Criação de painéis para visibilidade operacional ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [ Uso de painéis do Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)

 **Vídeos relacionados:** 
+ [ Create Cross Account & Cross Region CloudWatch Dashboards (Criar painéis do CloudWatch entre contas e entre regiões) ](https://www.youtube.com/watch?v=eIUZdaqColg)
+ [AWS re:Invent 2021 - Gain enterprise visibility with Nuvem AWS operation dashboards (AWS re:Invent 2021: obtenha visibilidade corporativa com painéis de operação do CloudWatch) ](https://www.youtube.com/watch?v=NfMpYiGwPGo)

 **Exemplos relacionados:** 
+ [ Um workshop de observabilidade ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Monitoramento de aplicações do Amazon CloudWatch ](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch/)

# OPERAÇÕES 9. Como compreender a integridade de suas operações?
<a name="ops-09"></a>

 Defina, capture e analise as métricas de operações para obter visibilidade dos eventos de operações, para que você possa tomar as ações apropriadas. 

**Topics**
+ [OPS09-BP01 Medir metas operacionais e KPIs com métricas](ops_operations_health_measure_ops_goals_kpis.md)
+ [OPS09-BP02 Comunicar o status e as tendências para garantir a visibilidade da operação](ops_operations_health_communicate_status_trends.md)
+ [OPS09-BP03 Revisar as métricas operacionais e priorizar a melhoria](ops_operations_health_review_ops_metrics_prioritize_improvement.md)

# OPS09-BP01 Medir metas operacionais e KPIs com métricas
<a name="ops_operations_health_measure_ops_goals_kpis"></a>

 Obtenha metas e KPIs que definam o sucesso das operações de sua organização e determine se as métricas os refletem. Defina linhas de base como ponto de referência e reavalie regularmente. Desenvolva mecanismos para coletar essas métricas das equipes para avaliação. 

 **Resultado desejado:** 
+  As metas e os KPIs das equipes de operações da organização foram publicados e compartilhados. 
+  Métricas que refletem esses KPIs são estabelecidas. Os exemplos podem incluir: 
  +  Profundidade da fila de tíquetes ou idade média do tíquete 
  +  Contagem de tíquetes agrupada por tipo de problema 
  +  Tempo gasto trabalhando em problemas com ou sem um procedimento operacional padronizado (SOP) 
  +  Tempo gasto na recuperação de uma falha no envio de código 
  +  Volume de chamadas 

 **Antipadrões comuns:** 
+  Os prazos de implantação são perdidos porque os desenvolvedores são contratados para realizar tarefas de solução de problemas. As equipes de desenvolvimento demandam mais pessoal, mas não conseguem quantificar quantos precisam porque o tempo perdido não pode ser medido. 
+  Um atendimento de Nível 1 foi configurado para lidar com chamadas de usuários. Com o tempo, mais workloads foram adicionadas, mas nenhum número de funcionários foi alocado para o atendimento de Nível 1. A satisfação do cliente sofre à medida que os tempos de atendimento aumentam e os problemas ficam mais tempo sem resolução, mas a gerência não vê indicadores disso, impedindo qualquer ação. 
+  Uma workload problemática foi transferida para uma equipe de operações separada para manutenção. Diferentemente de outras workloads, a nova não foi fornecida com documentação e runbooks adequados. Dessa forma, as equipes passam mais tempo solucionando problemas e tratando de falhas. No entanto, não há métricas que documentem isso, o que dificulta a prestação de contas. 

 **Benefícios de estabelecer esta prática recomendada:** Onde o monitoramento da workload mostra o estado de nossas aplicações e serviços, as equipes de operações de monitoramento fornecem aos proprietários uma visão das mudanças entre os consumidores dessas workloads, como as mudanças nas necessidades dos negócios. Meça a eficácia dessas equipes e avalie-as em relação às metas de negócios, criando métricas que possam refletir o estado das operações. As métricas podem destacar problemas de suporte ou identificar quando ocorrem desvios de uma meta de nível de serviço. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Agende um horário com líderes de negócios e partes interessadas para determinar as metas gerais do serviço. Determine quais devem ser as tarefas de várias equipes de operações e quais desafios elas podem enfrentar. Com isso, pense em indicadores-chave de performance (KPIs) que possam refletir essas metas operacionais. Pode ser a satisfação do cliente, o tempo desde a concepção do recurso até a implantação, o tempo médio de resolução de problemas e outros. 

 Trabalhando a partir de KPIs, identifique as métricas e as fontes de dados que podem refletir melhor essas metas. A satisfação do cliente pode ser uma combinação de várias métricas, como tempos de espera ou resposta de chamadas, índices de satisfação e tipos de problemas levantados. Os tempos de implantação podem ser a soma do tempo necessário para testes e implantação e quaisquer correções pós-implantação que precisem ser adicionadas. As estatísticas que mostram o tempo gasto em diferentes tipos de problemas (ou a contagem desses problemas) podem fornecer uma visão de onde é necessário um esforço direcionado. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Quick: uso de KPIs ](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html)
+ [ Amazon CloudWatch: uso de métricas ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [ Criação de painéis ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [ Como rastrear seus KPIs de otimização de custos com o painel de KPI ](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)

# OPS09-BP02 Comunicar o status e as tendências para garantir a visibilidade da operação
<a name="ops_operations_health_communicate_status_trends"></a>

 É necessário conhecer o estado de suas operações e a direção das tendências para identificar quando os resultados podem estar em risco, se o trabalho adicional pode ou não ser apoiado ou os efeitos que as mudanças tiveram em suas equipes. Durante eventos operacionais, ter páginas de status que os usuários e as equipes operacionais possam consultar para obter informações pode reduzir a pressão nos canais de comunicação e disseminar informações de forma proativa. 

 **Resultado desejado:** 
+  Os líderes de operações têm uma visão rápida para ver em que tipo de volume de chamadas suas equipes estão operando e quais esforços podem estar em andamento, como implantações. 
+  Os alertas são disseminados para as partes interessadas e comunidades de usuários quando ocorrem impactos nas operações normais. 
+  A liderança da organização e as partes interessadas podem verificar uma página de status em resposta a um alerta ou impacto e obter informações sobre um evento operacional, como pontos de contato, informações sobre tíquetes e tempos estimados de recuperação. 
+  Os relatórios são disponibilizados para a liderança e outras partes interessadas para mostrar estatísticas operacionais, como volumes de chamadas durante um período de tempo, índices de satisfação do usuário, números de tíquetes pendentes e suas idades. 

 **Antipadrões comuns:** 
+  Uma workload diminui, deixando um serviço indisponível. O volume de chamadas aumenta à medida que os usuários solicitam saber o que está acontecendo. Os gerentes aumentam o volume de solicitações para saber quem está resolvendo um problema. Várias equipes de operações duplicam esforços na tentativa de investigar. 
+  O desejo por uma nova capacidade faz com que vários funcionários sejam transferidos para um esforço de engenharia. Nenhum preenchimento é fornecido e os tempos de resolução de problemas aumentam. Essas informações não são capturadas e a liderança toma conhecimento do problema somente após várias semanas de comentários de insatisfação do usuário. 

 **Benefícios de estabelecer esta prática recomendada:** durante eventos operacionais em que a empresa é afetada, muito tempo e energia podem ser desperdiçados consultando informações de várias equipes tentando entender a situação. Ao estabelecer páginas de status e painéis amplamente divulgados, as partes interessadas podem obter rapidamente informações, como se um problema foi detectado ou não, quem liderou o problema ou quando é esperado um retorno às operações normais. Isso permite que os membros da equipe dediquem mais tempo à resolução de problemas e passem menos tempo comunicando o status a outras pessoas. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Crie painéis que mostrem as principais métricas atuais para suas equipes de operações e torne-as facilmente acessíveis, tanto para os líderes de operações quanto para a gerência. 

 Crie páginas de status que possam ser atualizadas rapidamente para mostrar quando um incidente ou evento está ocorrendo, quem é o proprietário e quem está coordenando a resposta. Compartilhe todas as etapas ou soluções alternativas que os usuários devem considerar nesta página e divulgue amplamente a localização. Incentive os usuários a verificar esse local primeiro quando confrontados com um problema desconhecido. 

 Colete e forneça relatórios que mostrem a integridade das operações ao longo do tempo e distribua-os aos líderes e tomadores de decisão para ilustrar o trabalho das operações junto com os desafios e as necessidades. 

 Compartilhe entre as equipes essas métricas e relatórios que melhor refletem as metas e os KPIs e onde eles foram influentes na promoção da mudança. Dedique tempo a essas atividades para aumentar a importância das operações dentro das equipes e entre elas. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Avalie o progresso ](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/measure-progress.html)
+ [ Criação de painéis para visibilidade da operação ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)

 **Soluções relacionadas:** 
+ [ Operações de dados ](https://aws.amazon.com/solutions/app-development/data-operations)

# OPS09-BP03 Revisar as métricas operacionais e priorizar a melhoria
<a name="ops_operations_health_review_ops_metrics_prioritize_improvement"></a>

 Reservar tempo e dedicar recursos para analisar o estado das operações garante que atender à linha de negócios do dia a dia continue sendo uma prioridade. Reúna líderes de operações e partes interessadas para revisar regularmente as métricas, reafirmar ou modificar metas e objetivos e priorizar melhorias. 

 **Resultado desejado:** 
+  Os líderes de operações e a equipe se reúnem regularmente para revisar as métricas durante um determinado período do relatório. Os desafios são comunicados, as vitórias são celebradas e as lições aprendidas são compartilhadas. 
+  As partes interessadas e os líderes de negócios são regularmente informados sobre o estado das operações e solicitados a fornecer informações sobre metas, KPIs e iniciativas futuras. As compensações entre prestação de serviços, operações e manutenção são discutidas e contextualizadas. 

 **Antipadrões comuns:** 
+  Um novo produto é lançado, mas as equipes operacionais de nível 1 e nível 2 não são adequadamente treinadas para dar suporte nem recebem pessoal adicional. Métricas que mostram a diminuição nos tempos de resolução de tíquetes e o aumento nos volumes de incidentes não são vistas pelos líderes. Uma ação é tomada semanas depois, quando os números de assinaturas começam a cair à medida que usuários insatisfeitos saem da plataforma. 
+  Um processo manual para realizar a manutenção de uma workload está em vigor há muito tempo. Embora o desejo de automatizar estivesse presente, essa era uma prioridade baixa, dada a baixa importância do sistema. No entanto, com o tempo, o sistema cresceu em importância e agora esses processos manuais consomem a maior parte do tempo das operações. Nenhum recurso está programado para fornecer mais ferramentas às operações, causando o esgotamento da equipe à medida que as workloads aumentam. A liderança percebe o que está acontecendo quando é relatado que funcionários estão indo trabalhar para outros concorrentes. 

 **Benefícios de estabelecer esta prática recomendada:** em algumas organizações, pode ser um desafio alocar o mesmo tempo e atenção dedicados à prestação de serviços e a novos produtos ou ofertas. Quando isso ocorre, a linha de negócios pode sofrer enquanto o nível de serviço esperado se deteriora lentamente. Isso ocorre porque as operações não mudam e evoluem com o crescimento dos negócios e logo podem ser deixadas para trás. Sem uma análise regular dos insights que as operações coletam, o risco para a empresa pode se tornar visível somente quando for tarde demais. Ao alocar tempo para revisar métricas e procedimentos tanto entre a equipe de operações quanto com a liderança, o papel crucial que as operações desempenham permanece visível e os riscos podem ser identificados muito antes de atingirem níveis críticos. As equipes de operações obtêm uma visão melhor das mudanças e iniciativas comerciais iminentes, permitindo que esforços proativos sejam realizados. A visibilidade da liderança nas métricas operacionais mostra o papel que essas equipes desempenham na satisfação do cliente, tanto interna quanto externa, e permite que elas avaliem melhor as opções de prioridades ou garantam que as operações tenham tempo e recursos para mudar e evoluir com novas iniciativas de negócios e workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Dedique tempo para analisar as métricas operacionais entre as partes interessadas e as equipes operacionais e analisar os dados do relatório. Coloque esses relatórios nos contextos das metas e objetivos da organização para determinar se eles estão sendo cumpridos. Identifique fontes de ambiguidade onde as metas não são claras ou onde pode haver conflitos entre o que é pedido e o que é dado. 

 Identifique onde o tempo, as pessoas e as ferramentas podem ajudar nos resultados das operações. Determine quais KPIs isso afetaria e quais deveriam ser as metas de sucesso. Revise regularmente para garantir que as operações tenham recursos suficientes para apoiar a linha de negócios. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Amazon Athena ](https://aws.amazon.com/athena/)
+ [ Amazon CloudWatch metrics and dimensions reference (Métricas do Amazon CloudWatch e referência de dimensões) ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [ Amazon Quick ](https://aws.amazon.com/quicksight/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [ Collect metrics and logs from Amazon EC2 instances and on-premises servers with the Amazon CloudWatch Agent (Coletar métricas e logs das instâncias do Amazon EC2 e de servidores on-premises com o agente do Amazon CloudWatch) ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [ Using Amazon CloudWatch metrics (Uso de métricas do Amazon CloudWatch) ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)

# OPERAÇÕES 10. Como gerenciar os eventos de workload e operações?
<a name="ops-10"></a>

 Prepare e valide procedimentos para responder a eventos, com o objetivo de minimizar a interrupção de sua carga de trabalho. 

**Topics**
+ [OPS10-BP01 Usar um processo para gerenciamento de eventos, incidentes e problemas](ops_event_response_event_incident_problem_process.md)
+ [OPS10-BP02 Ter um processo por alerta](ops_event_response_process_per_alert.md)
+ [OPS10-BP03 Priorizar eventos operacionais com base no impacto nos negócios](ops_event_response_prioritize_events.md)
+ [OPS10-BP04 Definir caminhos para escaladas](ops_event_response_define_escalation_paths.md)
+ [OPS10-BP05 Definir um plano de comunicação com o cliente para interrupções](ops_event_response_push_notify.md)
+ [OPS10-BP06 Comunicar o status por meio de painéis](ops_event_response_dashboards.md)
+ [OPS10-BP07 Automatizar respostas a eventos](ops_event_response_auto_event_response.md)

# OPS10-BP01 Usar um processo para gerenciamento de eventos, incidentes e problemas
<a name="ops_event_response_event_incident_problem_process"></a>

Sua organização tem processos para lidar com eventos, incidentes e problemas. *Eventos* são coisas que ocorrem em sua workload que talvez não precisem de intervenção. *Incidentes* são eventos que requerem intervenção. *Problemas* são eventos recorrentes que exigem intervenção ou que não podem ser resolvidos. São necessários processos para reduzir o impacto desses eventos sobre os negócios e garantir respostas adequadas.

Quando incidentes e problemas acontecem em sua workload, você precisa de processos para lidar com eles. Como você vai comunicar o status do evento às partes interessadas? Quem supervisiona e lidera a resposta? Quais são as ferramentas usadas para mitigar o evento? Esses são alguns exemplos de perguntas que você precisa responder para ter um processo de resposta sólido. 

Os processos devem estar documentados em um local central e disponíveis a todos envolvidos com a workload. Se você não tiver uma wiki ou um armazenamento central de documentos, use um repositório de controle de versão. Você vai manter esses planos atualizados à medida que os processos evoluem. 

Problemas são candidatos para automação. Esses eventos consomem o tempo que você poderia usar para inovar. Comece criando um processo repetível para mitigar o problema. Com o tempo, concentre-se na automação da mitigação ou correção do problema subjacente. Isso vai liberar tempo que você poderá dedicar ao desenvolvimento de melhorias para a workload. 

**Resultado desejado:** sua organização tem processos para lidar com eventos, incidentes e problemas. Esses processos são documentados e armazenados em um local central. Eles são atualizados à medida que os processos mudam. 

**Antipadrões comuns:** 
+  Um acidente ocorre durante um final de semana e o engenheiro de plantão não sabe o que fazer. 
+  Um cliente envia um e-mail informando que a aplicação está fora do ar. Você reinicializa o servidor para corrigir. Isso acontece com frequência. 
+  Há um incidente com várias equipes trabalhando de maneira independente para resolvê-lo. 
+  As implantações acontecem na workload sem serem registradas. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Você tem uma trilha de auditoria de eventos na workload. 
+  O tempo para se recuperar de um incidente diminui. 
+  Os membros da equipe podem resolver incidentes e problemas de maneira consistente. 
+  Há um esforço mais consolidado na hora de investigar um incidente. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

Implementar essa prática recomendada significa que você está monitorando os eventos da workload. Você tem processos para lidar com incidentes e problemas. Os processos são documentados, compartilhados e atualizados com frequência. Problemas são identificados, priorizados e corrigidos. 

 **Exemplo de cliente** 

A AnyCompany Retail tem uma parte de sua wiki interna dedicada a processos para gerenciamento de eventos, incidentes e problemas. Todos os eventos são enviados para o [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html). Os problemas são identificados como OpsItems no [OpsCenter do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) e priorizados para correção, reduzindo a mão de obra não diferenciada. À medida que os processos mudam, eles são atualizados na wiki interna. Eles usam o [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) para gerenciar incidentes e coordenar os esforços de mitigação. 

## Etapas da implementação
<a name="implementation-steps"></a>

1.  Eventos 
   +  Monitore os eventos que acontecem na workload, mesmo que nenhuma intervenção humana seja necessária. 
   +  Trabalhe com as partes interessadas da workload para desenvolver uma lista de eventos que devem ser monitorados. Alguns exemplos são implantações concluídas ou aplicações de correções bem-sucedidas. 
   +  Você pode usar serviços como [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) ou [Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) para gerar eventos personalizados para monitoramento. 

1.  Incidentes 
   +  Comece definindo o plano de comunicação para incidentes. Quais partes interessadas devem ser informadas? Como você vai mantê-las informadas? Quem supervisiona os esforços de coordenação? Recomendamos a configuração de um canal de bate-papo interno para comunicação e coordenação. 
   +  Defina caminhos de encaminhamento para as equipes que oferecem suporte à workload, principalmente se a equipe não tiver uma rotação de plantão. Com base em seu nível de suporte, você também pode registrar um caso no Suporte. 
   +  Crie um playbook para investigar o incidente. Isso deve incluir o plano de comunicação e etapas de investigação detalhadas. Inclua a verificação do [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) na investigação. 
   +  Documente seu plano de resposta a incidentes. Comunique o plano de gerenciamento de incidentes para que clientes internos e externos entendam as regras de engajamento e o que espera-se deles. Treine os membros de sua equipe sobre como usá-lo. 
   +  Os clientes podem usar o [Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) para configurar e gerenciar seu respectivo plano de resposta a incidentes. 
   +  Os clientes Enterprise Support podem solicitar o [Workshop de gerenciamento de incidentes](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) de seu gerente de conta técnico. Esse workshop guiado testa seu plano de resposta a incidentes e ajuda você a identificar áreas para melhoria. 

1.  Problemas 
   +  Os problemas devem ser identificados e monitorados em seu sistema de ITSM. 
   +  Identifique todos os problemas conhecidos e priorize-os em termos de esforço para corrigir e impacto na workload.   
![\[Matriz de prioridade de ação para priorizar os problemas.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/impact-effort-chart.png)
   +  Resolva problemas de alto impacto e pouco esforço primeiro. Com esses resolvidos, passe para os problemas do quadrante de baixo impacto e pouco esforço. 
   +  Você pode usar o [OpsCenter do Systems Manager](systems-manager/latest/userguide/OpsCenter.html) para identificar esses problemas, anexar runbooks a eles e monitorá-los. 

**Nível de esforço do plano de implementação:** médio. Você precisa de um processo e ferramentas para implementar essa prática recomendada. Documente seus processos e disponibilize-os para todos que estão associados à workload. Atualize-os com frequência. Você tem um processo para gerenciar problemas e mitigá-los ou corrigi-los. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS07-BP03 Usar runbooks para realizar procedimentos](ops_ready_to_support_use_runbooks.md): problemas conhecidos precisam de um runbook associado para que os esforços de mitigação sejam consistentes.
+  [OPS07-BP04 Usar manuais para investigar problemas](ops_ready_to_support_use_playbooks.md): os incidentes precisam ser investigados usando playbooks. 
+  [OPS11-BP02 Executar análise pós-incidente](ops_evolve_ops_perform_rca_process.md): sempre conduza uma autópsia depois de se recuperar de um incidente. 

 **Documentos relacionados:** 
+  [Atlassian: gerenciamento de incidentes na era de DevOps](https://www.atlassian.com/incident-management/devops) 
+  [Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+  [Gerenciamento de incidentes na era de DevOps e SRE](https://www.infoq.com/presentations/incident-management-devops-sre/) 
+  [PagerDuty: o que é gerenciamento de incidentes?](https://www.pagerduty.com/resources/learn/what-is-incident-management/) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2020: Incident management in a distributed organization (AWS re:Invent 2020: gerenciamento de incidentes em uma organização distribuída)](https://www.youtube.com/watch?v=tyS1YDhMVos) 
+  [AWS re:Invent 2021 - Building next-gen applications with event-driven architectures (AWS re:Invent 2021 - criando aplicações de última geração com arquiteturas orientadas por eventos)](https://www.youtube.com/watch?v=U5GZNt0iMZY) 
+  [AWS Supports You \$1 Exploring the Incident Management Tabletop Exercise (AWS apoia você \$1 Conhecendo a simulação teórica de gerenciamento de incidentes](https://www.youtube.com/watch?v=0m8sGDx-pRM) 
+  [AWS Systems Manager Incident Manager - AWS Virtual Workshops (AWS Systems Manager Incident Manager - workshops virtuais da AWS)](https://www.youtube.com/watch?v=KNOc0DxuBSY) 
+  [AWS What's Next ft. Incident Manager \$1 AWS Events (Próximos passos na AWS com Incident Manager \$1 Eventos da AWS)](https://www.youtube.com/watch?v=uZL-z7cII3k) 

 **Exemplos relacionados:** 
+  [workshop de ferramentas de gerenciamento e governança da AWS - OpsCenter](https://mng.workshop.aws/ssm/capability_hands-on_labs/opscenter.html) 
+  [Serviços proativos da AWS: workshop de gerenciamento de incidentes](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) 
+  [Como desenvolver uma aplicação orientada por eventos com o Amazon EventBridge](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/) 
+  [Como desenvolver arquiteturas orientadas por eventos na AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/63320e83-6abc-493d-83d8-f822584fb3cb/en-US/) 

 **Serviços relacionados:** 
+  [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 
+  [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 
+  [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 
+  [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [OpsCenter do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 

# OPS10-BP02 Ter um processo por alerta
<a name="ops_event_response_process_per_alert"></a>

 Tenha uma resposta bem-definida (runbook ou playbook), com um proprietário especificamente identificado, para qualquer evento para o qual você acione um alerta. Isso garante respostas eficazes e rápidas aos eventos de operações e evita que eventos acionáveis sejam ocultados por notificações menos valiosas. 

 **Antipadrões comuns:** 
+  Seu sistema de monitoramento apresenta um stream de conexões aprovadas junto com outras mensagens. O volume de mensagens é tão grande que você perde mensagens de erro periódicas que exigem sua intervenção. 
+  Você recebe um alerta de que o site está inoperante. Não há um processo definido para quando isso acontece. Você é forçado a adotar uma abordagem ad hoc para diagnosticar e resolver o problema. Desenvolver esse processo conforme o uso estende o tempo para recuperação. 

 **Benefícios do estabelecimento desta prática recomendada:** Ao alertar somente quando uma ação é necessária, você impede que alertas de valor baixo ocultem alertas de valor alto. Ao ter um processo para alertas sempre acionáveis, você permite uma resposta consistente e imediata a eventos em seu ambiente. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Processo por alerta: qualquer evento para o qual você dispara um alerta deve ter uma resposta bem-definida (runbook ou manual) com um proprietário identificado especificamente (por exemplo, indivíduo, equipe ou função) responsável pela execução bem-sucedida. O desempenho da resposta pode ser automatizado ou conduzido por outra equipe, mas o proprietário é responsável por garantir que o processo ofereça os resultados esperados. Ao ter esses processos, você garante respostas eficazes e rápidas aos eventos de operações e pode impedir que eventos acionáveis sejam ocultados por notificações menos valiosas. Por exemplo, o auto scaling pode ser aplicado para dimensionar um front-end da web, mas a equipe de operações pode ser responsável por garantir que as regras e os limites de auto scaling sejam adequados para as necessidades de carga de trabalho. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Recursos do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) 
+  [O que é o Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 

 **Vídeos relacionados:** 
+  [Build a monitoring plan](https://www.youtube.com/watch?v=OMmiGETJpfU) 

# OPS10-BP03 Priorizar eventos operacionais com base no impacto nos negócios
<a name="ops_event_response_prioritize_events"></a>

 Quando vários eventos demandarem intervenção, aborde primeiro os mais significativos para os negócios. Os impactos podem incluir perda de vida ou ferimentos, perda financeira ou danos à reputação ou confiança. 

 **Antipadrões comuns:** 
+  Você recebe uma solicitação de suporte para adicionar uma configuração de impressora para um usuário. Ao trabalhar no problema, você recebe uma solicitação de suporte informando que o site de varejo está inoperante. Depois de concluir a configuração da impressora para o usuário, você começa a trabalhar no problema do site. 
+  Você é notificado de que o site de varejo e o sistema de folha de pagamento estão inoperantes. Você não sabe para qual deve ter prioridade. 

 **Benefícios do estabelecimento desta prática recomendada:** A priorização de respostas aos incidentes com o maior impacto na empresa permite que você gerencie esse impacto. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Priorizar eventos operacionais com base no impacto empresarial: garanta que, quando vários eventos exigirem intervenção, aqueles que forem mais significativos para a empresa sejam abordados primeiro. Os impactos podem incluir perda de vida ou ferimentos, perda financeira, violações regulatórias ou danos à reputação ou à confiança. 

# OPS10-BP04 Definir caminhos para escaladas
<a name="ops_event_response_define_escalation_paths"></a>

 Defina caminhos de escalação em seus runbooks e playbooks, incluindo o que aciona a escalação e os procedimentos para escalação. Identifique especificamente os proprietários de cada ação para garantir respostas eficazes e rápidas aos eventos de operações. 

 Saiba quando é necessária uma decisão humana antes que medidas sejam tomadas. Trabalhe com os tomadores de decisão para que essa decisão seja tomada antecipadamente e a ação seja pré-aprovada, para que a MTTR não seja estendida aguardando uma resposta. 

 **Antipadrões comuns:** 
+  Seu site de varejo está inoperante. Você não compreende o runbook para recuperar o site. Você começa a chamar colegas na expectativa de que alguém possa ajudá-lo. 
+  Você recebe um caso de suporte para um aplicativo inacessível. Você não tem permissões para administrar o sistema. Você não sabe quem tem. Você tenta entrar em contato com o proprietário do sistema que abriu o caso e não há resposta. Você não tem contatos do sistema e seus colegas não estão familiarizados com ele. 

 **Benefícios do estabelecimento desta prática recomendada:** Ao definir escalações, gatilhos para escalação e procedimentos para escalação, você permite a adição sistemática de recursos a um incidente a uma taxa apropriada para o impacto. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Definir caminhos para as escaladas: defina caminhos para as escaladas em seus runbooks e manuais, incluindo que é acionado pela escalada e os respectivos procedimentos. Por exemplo, escalação de um problema de engenheiros de suporte para engenheiros de suporte seniores quando a resolução do problema não estiver nos runbooks ou quando um período de tempo predefinido tiver decorrido. Outro exemplo de um caminho de escalação apropriado é dos engenheiros de suporte sênior à equipe de desenvolvimento para uma carga de trabalho quando os playbooks não conseguem identificar um caminho para a correção ou quando um período de tempo predefinido decorre. Identifique especificamente os proprietários de cada ação para garantir respostas eficazes e rápidas aos eventos de operações. Os escalonamentos podem incluir terceiros. Por exemplo, um provedor de conectividade de rede ou um fornecedor de software. Os escalonamentos podem incluir tomadores de decisão autorizados identificados para sistemas impactados. 

# OPS10-BP05 Definir um plano de comunicação com o cliente para interrupções
<a name="ops_event_response_push_notify"></a>

 Defina e teste um plano de comunicação para interrupções do sistema que seja confiável para manter os clientes e as partes interessadas informados durante interrupções. Comunique-se diretamente com os usuários tanto quando os serviços que eles usam forem afetados como quando os serviços voltarem ao normal. 

 **Resultado desejado:** 
+  Você tem um plano de comunicação para situações que vão desde manutenção agendada até grandes falhas inesperadas, incluindo invocação de planos de recuperação de desastres. 
+  Nas comunicações, você fornece informações claras e transparentes sobre problemas do sistema para ajudar os clientes a evitar dúvidas sobre o desempenho dos sistemas. 
+  Você usa mensagens de erro personalizadas e páginas de status para reduzir o pico nas solicitações de suporte técnico e mantém os usuários informados. 
+  O plano de comunicação é testado regularmente para verificar se ele ocorrerá como planejado no caso de uma interrupção real. 

 **Antipadrões comuns:** 
+ Ocorre uma interrupção da workload, mas você não tem um plano de comunicação. Os usuários sobrecarregam o sistema de tíquetes com solicitações, pois não têm informações sobre a interrupção.
+ Você envia uma notificação por e-mail aos usuários durante uma interrupção. Ela não contém um prazo para a restauração do serviço, então os usuários não conseguem se planejar em torno da interrupção.
+ Há um plano de comunicação para interrupções, mas ele nunca foi testado. Ocorre uma interrupção e o plano de comunicação falha, pois faltou uma etapa fundamental que poderia ter sido identificada no teste.
+  Durante uma interrupção, você envia uma notificação aos usuários com muitas informações e detalhes técnicos sob o NDA da AWS. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Manter a comunicação durante as interrupções garante que os clientes possam ver o andamento da resolução dos problemas e o tempo previsto para que ela ocorra. 
+  Desenvolver um plano de comunicação bem-definido garante que os clientes e usuários finais estejam bem-informados para que possam tomar medidas adicionais visando a mitigar o impacto das interrupções. 
+  Com uma comunicação adequada e maior ciência acerca de interrupções planejadas e não planejadas, é possível melhorar a satisfação dos clientes, limitar reações não pretendidas e gerar a retenção dos clientes. 
+  Uma comunicação transparente e em tempo hábil acerca da interrupção do sistema gera credibilidade e estabelece a confiança necessária para manter seu relacionamento com os clientes. 
+  Uma estratégia de comunicação comprovada durante uma interrupção ou crise reduz a especulação e os rumores que poderiam atrapalhar sua capacidade de recuperação. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Os planos de comunicação que mantêm os clientes informados durante interrupções são holísticos e abrangem várias interfaces, incluindo páginas de erro voltadas para o cliente, mensagens de erro de API personalizadas, banners sobre o status do sistema e páginas de status de integridade. Se o sistema incluir usuários registrados, é possível comunicar-se por canais de mensagens, como e-mail, SMS ou notificações por push, para enviar conteúdo com mensagens personalizadas aos clientes. 

 **Ferramentas de comunicação com o cliente** 

 Como uma primeira linha de defesa, as aplicações web e móveis devem fornecer mensagens de erro amistosas e informativas durante uma interrupção e devem poder redirecionar o tráfego para uma página de status. O [Amazon CloudFront](https://aws.amazon.com/cloudfront/) é uma rede de entrega de conteúdo (CDN) que inclui recursos para definir e entregar conteúdo de erro personalizado. As páginas de erro personalizadas no CloudFront são uma ótima camada inicial de mensagens para os clientes para interrupções no nível de componentes. O CloudFront também pode simplificar o gerenciamento e a ativação da página de status para interceptar todas as solicitações durante interrupções planejadas e não planejadas. 

 As mensagens de erro de API personalizadas podem ajudar a detectar e reduzir o impacto quando as interrupções são isoladas a serviços discretos. O [Amazon API Gateway](https://aws.amazon.com/api-gateway/) permite configurar respostas personalizadas para as APIs REST. Isso permite fornecer mensagens claras e significativas para os consumidores da API quando o API Gateway não puder acessar os serviços de back-end. As mensagens personalizadas também podem ser usadas para dar suporte a notificações e conteúdos de banner sobre a interrupção quando um recurso específico do sistema é danificado devido a interrupções no nível do serviço. 

 As mensagens diretas são o tipo mais personalizado de mensagens para o cliente. O [Amazon Pinpoint](https://aws.amazon.com/pinpoint/) é um serviço gerenciado para comunicações escaláveis de vários canais. O Amazon Pinpoint permite criar campanhas que possam transmitir mensagens amplamente pela base de clientes afetados por SMS, e-mail, mensagem de voz, notificações por push ou canais personalizados definidos por você. Ao gerenciar as mensagens com o Amazon Pinpoint, as campanhas de mensagem são bem-definidas, testáveis e podem ser aplicadas de forma inteligente a segmentos de clientes-alvo. Depois de serem estabelecidas, as campanhas podem ser agendadas ou acionadas por eventos e podem ser facilmente testadas. 

 **Exemplo de clientes** 

 Quando a workload é prejudicada, a Loja UmaEmpresa envia uma notificação por e-mail aos usuários. O e-mail descreve qual funcionalidade da empresa foi prejudicada e fornece uma estimativa realista de quando o serviço será restaurado. Além disso, há uma página de status que mostra informações em tempo real sobre a integridade da workload. O plano de comunicação é testado em um ambiente de desenvolvimento duas vezes ao ano para validar sua eficácia. 

 **Etapas da implementação** 

1.  Determine os canais de comunicação para sua estratégia de mensagens. Considere os aspectos da arquitetura da aplicação e determine a melhor estratégia para fornecer feedback aos clientes. Isso pode incluir uma ou mais das estratégias de orientação descritas, incluindo páginas de erro e de status, respostas de erro de API personalizadas ou mensagens diretas. 

1.  Elabore páginas de status para a aplicação. Se você determinou que as páginas de status ou de erro personalizadas são adequadas para os clientes, é necessário elaborar o conteúdo e as mensagens para essas páginas. As páginas de erro explicam aos usuários por que uma aplicação não está disponível, quando ela pode ficar disponível novamente e o que pode ser feito enquanto isso. Se a aplicação usar o Amazon CloudFront, é possível fornecer [respostas de erro personalizadas](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GeneratingCustomErrorResponses.html) ou usar o Lambda no Edge para [traduzir erros](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-update-error-status-examples) e reescrever o conteúdo da página. O CloudFront também permite mudar os destinos do conteúdo da aplicação para uma origem de conteúdo estático do [Amazon S3](https://aws.amazon.com/s3/) que contém sua página de status da interrupção ou de manutenção. 

1.  Elabore o conjunto de status de erro de API correto para seu serviço. As mensagens de erro produzidas pelo API Gateway quando ele não consegue acessar os serviços de back-end, além das exceções no nível do serviço, podem não conter mensagens amistosas adequadas para exibição aos usuários finais. Sem precisar fazer alterações no código dos serviços de back-end, é possível configurar as [respostas de erro personalizadas](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html) do API Gateway para mapear os códigos de resposta HTTP para mensagens de erro de API selecionadas. 

1.  Elabore mensagens de uma perspectiva empresarial para que elas sejam relevantes aos usuários finais do sistema e não contenham detalhes técnicos. Considere seu público e alinhe suas mensagens. Por exemplo, você pode conduzir os usuários internos para uma solução alternativa ou um processo manual que utiliza sistemas alternativos. Os usuários externos podem ser solicitados a aguardar até que o sistema seja restaurado ou assinar as atualizações para receber uma notificação quando o sistema for restaurado. Defina mensagens aprovadas para vários cenários, incluindo interrupções não planejadas, manutenção planejada e falhas parciais do sistema quando um recurso específico pode estar danificado ou indisponível. 

1.  Modele e automatize as mensagens para os clientes. Depois de estabelecer o conteúdo das mensagens, é possível usar o [Amazon Pinpoint](https://docs.aws.amazon.com/pinpoint/latest/developerguide/welcome.html) ou outras ferramentas para automatizar sua campanha de mensagens. Com o Amazon Pinpoint, é possível criar segmentos de destino de clientes para usuários afetados específicos e transformar as mensagens em modelos. Consulte o [Tutorial do Amazon Pinpoint](https://docs.aws.amazon.com/pinpoint/latest/developerguide/tutorials.html) para entender como configurar uma campanha de mensagens. 

1.  Evite o acoplamento forte de recursos de mensagens ao sistema voltado para o cliente. Sua estratégia de mensagens não deve depender fortemente de serviços ou armazenamentos de dados do sistema para verificar se é possível enviar mensagens quando ocorrerem interrupções. Considere desenvolver a capacidade de enviar mensagens a mais de [uma região ou zona de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_multiaz_region_system.html) para disponibilidade de mensagens. Se você estiver usando os serviços da AWS para enviar mensagens, utilize as operações do plano de dados sobre as [operações do ambiente de gerenciamento](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html) para invocar suas mensagens. 

 **Nível de esforço do plano de implementação:** alto. Desenvolver um plano de comunicação e os mecanismos para enviá-lo pode exigir um esforço significativo. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS07-BP03 Usar runbooks para realizar procedimentos](ops_ready_to_support_use_runbooks.md) – Seu plano de comunicação deve ter um runbook associado a ele para que seus funcionários saibam como responder. 
+  [OPS11-BP02 Executar análise pós-incidente](ops_evolve_ops_perform_rca_process.md) – Depois de uma interrupção, realize uma análise pós-incidente para identificar mecanismos, a fim de evitar outra interrupção. 

 **Documentos relacionados:** 
+ [ Error Handling Patterns in Amazon API Gateway and AWS Lambda](https://aws.amazon.com/blogs/compute/error-handling-patterns-in-amazon-api-gateway-and-aws-lambda/)(Padrões de tratamento de erros no Amazon API Gateway e no AWS Lambda)
+ [ Amazon API Gateway responses ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html#supported-gateway-response-types)(Respostas do Amazon API Gateway)

 **Exemplos relacionados:** 
+ [AWS Health Dashboard ](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/)(Painel do AWS Health)
+ [ Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region ](https://aws.amazon.com/message/12721/) (Resumo do evento de serviço da AWS na região Virgínia do Norte (US-EAST-1)

 **Serviços relacionados:** 
+ [AWS Support](https://aws.amazon.com/premiumsupport/)
+ [ Contrato de Cliente da AWS](https://aws.amazon.com/agreement/)
+ [ Amazon CloudFront ](https://aws.amazon.com/cloudfront/)
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [ Amazon Pinpoint ](https://aws.amazon.com/pinpoint/)
+ [ Amazon S3 ](https://aws.amazon.com/s3/)

# OPS10-BP06 Comunicar o status por meio de painéis
<a name="ops_event_response_dashboards"></a>

 Forneça painéis personalizados para seus públicos-alvo (por exemplo, equipes técnicas internas, liderança e clientes) para comunicar o status operacional atual dos negócios e fornecer métricas de interesse. 

 Você pode criar painéis usando o [Painéis do Amazon CloudWatch](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) em páginas de início personalizáveis no console do CloudWatch. Ao usar serviços de inteligência de negócios, como o [Quick](https://aws.amazon.com/quicksight/) , você pode criar e publicar painéis interativos da carga de trabalho e da integridade operacional (por exemplo, taxas de pedidos, usuários conectados e tempos de transação). Crie painéis contendo visualizações em nível de sistema e de negócios de suas métricas. 

 **Antipadrões comuns:** 
+  Mediante solicitação, você executa um relatório sobre a utilização atual da aplicação para a gerência. 
+  Durante um incidente, você é contatado a cada vinte minutos por um proprietário do sistema preocupado, que deseja saber se ele já foi corrigido. 

 **Benefícios do estabelecimento desta prática recomendada:** Ao criar painéis, você permite o acesso por autoatendimento às informações, permitindo que os clientes se informem e determinem se precisam executar ações. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Comunicar o status por meio de painéis: forneça painéis personalizados para seus públicos-alvo (por exemplo, equipes técnicas internas, liderança e clientes) para comunicar o status operacional atual dos negócios e fornecer métricas de interesse. Fornecer uma opção de autoatendimento para informações de status reduz a interrupção das solicitações de status de campo pela equipe de operações. Os exemplos incluem os painéis do Amazon CloudWatch e o AWS Health Dashboard. 
  +  [CloudWatch dashboards create and use customized metrics views (Os painéis do CloudWatch criam e usam visualizações de métricas personalizadas)](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Quick](https://aws.amazon.com/quicksight/) 
+  [CloudWatch dashboards create and use customized metrics views (Os painéis do CloudWatch criam e usam visualizações de métricas personalizadas)](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 

# OPS10-BP07 Automatizar respostas a eventos
<a name="ops_event_response_auto_event_response"></a>

 Automatize as respostas aos eventos para reduzir erros causados por processos manuais e garantir respostas rápidas e consistentes. 

 Existem várias maneiras de automatizar a execução de ações de runbook e manual na AWS. Para responder a um evento de alteração de estado nos seus recursos da AWS, ou de seus próprios eventos personalizados, você deve criar [regras do CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) para acionar respostas por meio de alvos do CloudWatch (por exemplo, funções do Lambda, tópicos do Amazon Simple Notification Service (Amazon SNS), tarefas do Amazon ECS e automação do AWS Systems Manager). 

 Para responder a uma métrica que ultrapassa um limite para um recurso (por exemplo, tempo de espera), você deve criar [alarmes do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) para executar uma ou mais ações usando as ações do Amazon EC2, as ações do Auto Scaling ou enviar uma notificação para um tópico do Amazon SNS. Se for necessário executar ações personalizadas em resposta a um alarme, chame o Lambda por meio de uma notificação do Amazon SNS. Use o Amazon SNS para publicar notificações de eventos e mensagens de escalação para manter as pessoas informadas. 

 A AWS também é compatível com sistemas de terceiros por meio das APIs e SDKs de serviço da AWS. Existem várias ferramentas de monitoramento fornecidas por parceiros da AWS e por terceiros que permitem monitoramento, notificações e respostas. Algumas dessas ferramentas são New Relic, Splunk, Loggly, SumoLogic e Datadog. 

 Mantenha procedimentos manuais críticos disponíveis para uso quando houver falha em procedimentos automatizados. 

 **Antipadrões comuns:** 
+  Um desenvolvedor verifica seu código. Esse evento poderia ter sido usado para iniciar uma compilação e, em seguida, executar testes, mas, em vez disso, nada acontece. 
+  Sua aplicação registra um erro específico em log antes de parar de funcionar. O procedimento para reiniciar o aplicativo é bem compreendido e pode ter um script. Você pode usar o evento de log para invocar um script e reiniciar o aplicativo. Em vez disso, quando o erro acontece às 3 da manhã de domingo, você é despertado como o recurso de plantão responsável pela correção do sistema. 

 **Benefícios do estabelecimento desta prática recomendada:** Ao usar respostas automatizadas a eventos, você reduz o tempo de resposta e limita a introdução de erros oriundos de atividades manuais. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Automatizar respostas a eventos: automatize respostas a eventos para reduzir erros causados por processos manuais e garantir respostas rápidas e consistentes. 
  +  [O que é o Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 
  +  [Criação de uma regra do CloudWatch Events que aciona um evento](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html) 
  +  [Criação de uma regra do CloudWatch Events que aciona uma chamada de API da AWS usando o AWS CloudTrail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html) 
  +  [Exemplos de eventos do CloudWatch Events de serviços compatíveis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Recursos do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) 
+  [Exemplos de eventos do CloudWatch Events de serviços compatíveis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html) 
+  [Criação de uma regra do CloudWatch Events que aciona uma chamada de API da AWS usando o AWS CloudTrail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html) 
+  [Criação de uma regra do CloudWatch Events que aciona um evento](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html) 
+  [O que é o Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 

 **Vídeos relacionados:** 
+  [Build a monitoring plan](https://www.youtube.com/watch?v=OMmiGETJpfU) 

 **Exemplos relacionados:** 

# Evoluir
<a name="a-evolve"></a>

**Topics**
+ [OPERAÇÕES 11. Como evoluir as operações?](ops-11.md)

# OPERAÇÕES 11. Como evoluir as operações?
<a name="ops-11"></a>

 Dedique tempo e recursos para a melhoria incremental praticamente contínua, a fim de aumentar a eficácia e a eficiência de suas operações. 

**Topics**
+ [OPS11-BP01 Ter um processo para a melhoria contínua](ops_evolve_ops_process_cont_imp.md)
+ [OPS11-BP02 Executar análise pós-incidente](ops_evolve_ops_perform_rca_process.md)
+ [OPS11-BP03 Implementar loops de feedback](ops_evolve_ops_feedback_loops.md)
+ [OPS11-BP04 Realizar o gerenciamento de conhecimento](ops_evolve_ops_knowledge_management.md)
+ [OPS11-BP05 Definir motivadores de melhoria](ops_evolve_ops_drivers_for_imp.md)
+ [OPS11-BP06 Validar insights](ops_evolve_ops_validate_insights.md)
+ [OPS11-BP07 Fazer análises das métricas de operações](ops_evolve_ops_metrics_review.md)
+ [OPS11-BP08 Documentar e compartilhar as lições aprendidas](ops_evolve_ops_share_lessons_learned.md)
+ [OPS11-BP09 Alocar tempo para fazer melhorias](ops_evolve_ops_allocate_time_for_imp.md)

# OPS11-BP01 Ter um processo para a melhoria contínua
<a name="ops_evolve_ops_process_cont_imp"></a>

Avalie sua workload em relação às práticas recomendadas de arquitetura interna e externa. Realize análises da workload pelo menos uma vez ao ano. Priorize as oportunidades de melhoria em sua cadência de desenvolvimento de software. 

 **Resultado desejado:** 
+  Você analisa sua workload em relação às práticas recomendadas de arquitetura pelo menos anualmente. 
+  As oportunidades de melhoria recebem a mesma prioridade em seu processo de desenvolvimento de software. 

 **Antipadrões comuns:** 
+ Você não realizou uma análise de arquitetura em sua workload desde que foi implantada há vários anos.
+ As oportunidades de melhoria recebem uma prioridade mais baixa e permanecem no backlog.
+  Não há um padrão para implementar modificações nas práticas recomendadas da organização. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Sua workload é mantida atualizada em relação às práticas recomendadas de arquitetura. 
+  A evolução de sua workload é realizada de forma deliberada. 
+  Você pode utilizar as práticas recomendadas da organização para melhorar todas as workloads. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Pelo menos anualmente, você realiza uma análise arquitetônica de sua workload. Usando práticas recomendadas internas e externas, avalie sua workload e identifique oportunidades de melhoria. Priorize as oportunidades de melhoria em sua cadência de desenvolvimento de software. 

 **Exemplo de clientes** 

 Todas as workloads da AnyCompany Retail passam por um processo anual de análise da arquitetura. A empresa desenvolveu a própria lista de verificação de práticas recomendadas que se aplicam a todas as workloads. Usando o recurso Custom Lens do AWS Well-Architected Tool, foram realizadas análises com a ferramenta e Custom Lens de práticas recomendadas. As oportunidades de melhoria geradas pelas análises recebem prioridade nos sprints de software. 

 **Etapas da implementação** 

1.  Realize análises de arquitetura periódicas de sua workload de produção pelo menos anualmente. Use um padrão de arquitetura documentado que inclua práticas recomendadas específicas da AWS. 

   1.  Recomendamos usar seus próprios padrões definidos internamente para essas análises. Se você não tiver um padrão interno, recomendamos usar a AWS Well-Architected Framework. 

   1.  Você pode usar o AWS Well-Architected Tool para criar um Custom Lens de suas práticas recomendadas internas e realizar a análise de sua arquitetura. 

   1.  Os clientes podem entrar em contato com o arquiteto de soluções da AWS para realizar uma Análise da Well-Architected Framework da workload deles. 

1.  Priorize as oportunidades de melhoria identificadas durante a análise em seu processo de desenvolvimento de software. 

 **Nível de esforço do plano de implementação:** baixo. É possível usar a AWS Well-Architected Framework para realizar sua análise de arquitetura anual. 

### Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS11-BP02 Executar análise pós-incidente](ops_evolve_ops_perform_rca_process.md): análise pós-incidente é outro gerador de itens de melhoria. Insira as lições aprendidas em sua lista interna de práticas recomendadas de arquitetura. 
+  [OPS11-BP08 Documentar e compartilhar as lições aprendidas](ops_evolve_ops_share_lessons_learned.md): à medida que você desenvolve suas próprias práticas recomendadas de arquitetura, compartilhe-as em sua organização. 

 **Documentos relacionados:** 
+ [AWS Well-Architected Tool: Custom lenses ](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [AWS Whitepaper sobre Well-Architected: The review process ](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-review-process.html) (O processo de revisão)
+ [ Customize Well-Architected Reviews using Custom Lenses and the AWS Well-Architected Tool](https://aws.amazon.com/blogs/mt/customize-well-architected-reviews-using-custom-lenses-and-the-aws-well-architected-tool/) (Personalizar as Revisões de Well-Architected com o uso de Custom Lenses e o AWS Well-Architected Tool)
+ [ Implementing the AWS Well-Architected Custom Lens lifecycle in your organization ](https://aws.amazon.com/blogs/architecture/implementing-the-aws-well-architected-custom-lens-lifecycle-in-your-organization/) (Implementar o ciclo de vida do AWS Well-Architected Custom Lens em sua organização)

 **Vídeos relacionados:** 
+ [ Well-Architected Labs - Level 100: Custom Lenses on AWS Well-Architected Tool](https://www.wellarchitectedlabs.com/well-architectedtool/100_labs/100_custom_lenses_on_watool/) (Well-Architected Labs: nível 100: Custom Lenses no AWS Well-Architected Tool)

 **Exemplos relacionados:** 
+ [ O AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)

# OPS11-BP02 Executar análise pós-incidente
<a name="ops_evolve_ops_perform_rca_process"></a>

 Analise os eventos que afetam o cliente e identifique os fatores que contribuem e as ações preventivas. Use essas informações para desenvolver mitigações para limitar ou evitar recorrência. Desenvolva procedimentos para respostas rápidas e eficazes. Comunique os fatores contribuintes e as ações corretivas conforme apropriado, de acordo com o público-alvo. 

 **Antipadrões comuns:** 
+  Você administra um servidor de aplicativos. Aproximadamente a cada 23 horas e 55 minutos, todas as sessões ativas são encerradas. Você tentou identificar o que está errado no servidor de aplicativos. Você suspeita que possa ser um problema de rede, mas não consegue obter colaboração da equipe da rede, pois ela está muito ocupada para ajudar você. Você não tem um processo predefinido a seguir para obter suporte e coletar as informações necessárias para determinar o que está acontecendo. 
+  Você teve perda de dados em sua carga de trabalho. Esta é a primeira vez que isso acontece e a causa não é óbvia. Você decide que não é importante porque pode recriar os dados. A perda de dados começa a ocorrer com maior frequência, afetando seus clientes. Isso também coloca uma sobrecarga operacional adicional à medida que você restaura os dados ausentes. 

 **Benefícios do estabelecimento desta prática recomendada:** Ter processos predefinidos para determinar componentes, condições, ações e eventos que contribuíram para um incidente permite identificar oportunidades de melhoria. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Usar um processo para determinar os fatores contribuintes: analise todos os incidentes que impactam os clientes. Tenha um processo para identificar e documentar as causas de um incidente para que você possa desenvolver atenuações para limitar ou impedir a recorrência e para desenvolver procedimentos para respostas rápidas e eficazes. Se for apropriado, comunique as causas de forma direcionada para o público-alvo. 

# OPS11-BP03 Implementar loops de feedback
<a name="ops_evolve_ops_feedback_loops"></a>

Os loops de feedback fornecem insights que levem a ações concretas e orientem a tomada de decisões. Crie loops de feedback em seus procedimentos e workloads. Isso ajuda a identificar problemas e áreas que precisam de melhorias. Eles também validam os investimentos feitos em melhorias. Esses loops de feedback são a base para melhorar continuamente sua workload.

 Os loops de feedback se enquadram em duas categorias: *feedback imediato* e *análise retrospectiva*. O feedback imediato é coletado por meio da avaliação do desempenho e dos resultados das atividades de operações. Esse feedback vem de membros da equipe, clientes ou do resultado automático da atividade. O feedback imediato é recebido de elementos como testes A/B e do envio de novos recursos, e é essencial para antecipar-se à falha. 

 A análise retrospectiva é realizada regularmente para obter feedback da avaliação de resultados e métricas operacionais ao longo do tempo. Essa retrospectiva ocorre ao final de um sprint, com certa frequência ou após grandes lançamentos ou eventos. Esse tipo de loop de feedback valida investimentos em operações ou na workload. Ele ajuda a medir o sucesso e valida sua estratégia. 

 **Resultado desejado:** o feedback imediato e a análise retrospectiva são usados para promover melhorias. Há um mecanismo para obter o feedback de usuários e membros da equipe. A análise retrospectiva é usada para identificar tendências que promovam melhorias. 

 **Antipadrões comuns:** 
+ Você lança um recurso, mas não há uma maneira de receber feedback de clientes sobre ele.
+ Depois de investir em melhorias de operações, você não realiza uma retrospectiva para validá-las.
+ Você coleta feedback dos clientes, mas não os avalia regularmente.
+ Os loops de feedback levam a itens de ação propostos, mas não estão incluídos no processo de desenvolvimento de software.
+  Os clientes não recebem feedback sobre as melhorias que propuseram. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Você pode trabalhar partindo do feedback do cliente para gerar outros recursos. 
+  A cultura da sua organização pode reagir às mudanças mais rapidamente. 
+  As tendências são usadas para identificar oportunidades de melhoria. 
+  As retrospectivas validam os investimentos feitos na workload e nas operações. 

 **Nível de risco exposto se essa prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A implementação dessa prática recomendada significa que você usa tanto o feedback imediato como a análise de retrospectiva. Esses loops de feedback geram melhorias. Há muitos mecanismos para o feedback imediato, incluindo pesquisas, enquetes com clientes ou formulários de feedback. Sua organização também pode usar as retrospectivas para identificar oportunidades de melhoria e validar iniciativas. 

 **Exemplo de cliente** 

 A Loja UmaEmpresa criou um formulário online pelo qual os clientes podem dar feedback ou relatar problemas. Durante as reuniões semanais, o feedback dos usuários é avaliado pela equipe de desenvolvimento de software. O feedback é usado regularmente para conduzir a evolução da plataforma. É feita uma retrospectiva ao final de cada sprint para identificar itens que eles desejam melhorar. 

## Etapas da implementação
<a name="implementation-steps"></a>

1. Feedback imediato
   +  Você precisa de um mecanismo para receber feedback de clientes e membros da equipe. Suas atividades de operações também podem ser configuradas para oferecer feedback automático. 
   +  Sua organização precisa de um processo para avaliar esse feedback, determinar o que precisa ser melhorado e programar a melhoria. 
   +  O feedback deve ser adicionado ao seu processo de desenvolvimento de software. 
   +  À medida que você faz melhorias, dê um retorno a quem enviou o feedback. 
     +  Você pode usar o [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) para criar e monitorar essas melhorias como [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-working-with-OpsItems.html).

1.  Análise retrospectiva 
   +  Faça retrospectivas ao final de um ciclo de desenvolvimento, com certa frequência ou após um grande lançamento. 
   +  Faça uma reunião de retrospectiva com as partes interessadas envolvidas na workload. 
   +  Crie três colunas em um quadro branco ou uma planilha: “Parar”, “Iniciar” e “Manter”. 
     +  *A coluna “Parar”* é para o que você deseja que a equipe pare de fazer. 
     +  *A coluna “Iniciar”* é para ideias que você deseja começar a fazer. 
     +  *A coluna “Manter”* é para os itens que você deseja continuar fazendo. 
   +  Caminhe pela sala e colete o feedback das partes interessadas. 
   +  Priorize o feedback. Atribua ações e partes interessadas aos itens de “Iniciar” e “Manter”. 
   +  Adicione as ações ao processo de desenvolvimento de software e comunique as atualizações de status às partes interessadas à medida que as melhorias são implementadas. 

 **Nível de esforço do plano de implementação:** médio. Para implementar essa prática recomendada, você precisa de uma maneira para receber feedback imediato e analisá-lo. Além disso, você precisa estabelecer um processo de análise de retrospectiva. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS01-BP01 Avaliar as necessidades dos clientes externos](ops_priorities_ext_cust_needs.md): loops de feedback são um mecanismo para coletar as necessidades de clientes externos. 
+  [OPS01-BP02 Avalie as necessidades dos clientes internos](ops_priorities_int_cust_needs.md): as partes interessadas internas podem usar loops de feedback para comunicar necessidades e requisitos. 
+  [OPS11-BP02 Executar análise pós-incidente](ops_evolve_ops_perform_rca_process.md): a análise pós-incidente é uma forma importante de análise retrospectiva conduzida após os incidentes. 
+  [OPS11-BP07 Fazer análises das métricas de operações](ops_evolve_ops_metrics_review.md): as avaliações das métricas de operações identificam tendências e áreas para melhorias. 

 **Documentos relacionados:** 
+  [7 Pitfalls to Avoid When Building a CCOE (Sete obstáculos a evitar ao criar um CCoE)](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/) 
+  [Atlassian Team Playbook - Retrospectives (Manual da equipe do Atlassian: retrospectivas)](https://www.atlassian.com/team-playbook/plays/retrospective) 
+  [Email Definitions: Feedback Loops (Definições de e-mail: loops de feedback)](https://aws.amazon.com/blogs/messaging-and-targeting/email-definitions-feedback-loops/) 
+  [Establishing Feedback Loops Based on the AWS Well-Architected Framework Review (Como estabelecer loops de feedback com base na avaliação do AWS Well-Architected Framework)](https://aws.amazon.com/blogs/architecture/establishing-feedback-loops-based-on-the-aws-well-architected-framework-review/) 
+  [IBM Garage Methodology - Hold a retrospective (Metodologia IBM Garage: faça uma retrospectiva)](https://www.ibm.com/garage/method/practices/learn/practice_retrospective_analysis/) 
+  [Investopedia – The PDCS Cycle (Investopédia: o ciclo de PDCS)](https://www.investopedia.com/terms/p/pdca-cycle.asp) 
+  [Maximizing Developer Effectiveness by Tim Cochran (Como maximizar a eficácia do desenvolvedor, por Tim Cochran)](https://martinfowler.com/articles/developer-effectiveness.html) 
+  [Operations Readiness Reviews (ORR) Whitepaper - Iteration (Whitepaper de análises de preparação de operações (ORR): iteração)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html) 
+  [TIL CSI - Continual Service Improvement (CSI de TIL: melhoria de serviço contínua)](https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement)
+  [When Toyota met e-commerce: Lean at Amazon (Quando a Toyota chegou ao comércio eletrônico: confiança na Amazon)](https://www.mckinsey.com/capabilities/operations/our-insights/when-toyota-met-e-commerce-lean-at-amazon) 

 **Vídeos relacionados:** 
+  [Building Effective Customer Feedback Loops (Como criar loops de feedback eficazes de clientes)](https://www.youtube.com/watch?v=zz_VImJRZ3U) 

 **Exemplos relacionados: ** 
+  [Astuto - Open source customer feedback tool (Astuto: ferramenta de código aberto de feedback de clientes)](https://github.com/riggraz/astuto) 
+  [AWS Solutions - QnABot on AWS (Soluções da AWS: QnABot na AWS)](https://aws.amazon.com/solutions/implementations/qnabot-on-aws/) 
+  [Fider - A platform to organize customer feedback (Fider: uma plataforma para organizar feedback de clientes)](https://github.com/getfider/fider) 

 **Serviços relacionados:** 
+  [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 

# OPS11-BP04 Realizar o gerenciamento de conhecimento
<a name="ops_evolve_ops_knowledge_management"></a>

O gerenciamento de conhecimento ajuda os membros da equipe a encontrar as informações para realizar o trabalho deles. Nas organizações de aprendizagem, as informações são compartilhadas livremente, o que capacita as pessoas. As informações podem ser descobertas ou pesquisadas. As informações são precisas e atualizadas. Os mecanismos existem para criar informações, atualizar informações existentes e arquivar informações desatualizadas. O exemplo mais comum de uma plataforma de gerenciamento de conhecimento é um sistema de gerenciamento de conteúdo como uma wiki. 

 **Resultado desejado:** 
+  Os membros da equipe têm acesso a informações precisas e em tempo hábil. 
+  As informações podem ser pesquisadas. 
+  Existem mecanismos para adicionar, atualizar e arquivar informações. 

 **Antipadrões comuns:** 
+ Não há um armazenamento de conhecimento centralizado. Os membros da equipe gerenciam suas próprias notas nas máquinas locais.
+  Você tem uma wiki hospedada pela própria empresa, mas nenhum mecanismo para gerenciar informações, resultando em informações desatualizadas. 
+  Alguém identifica a ausência de informações, mas não há nenhum processo para solicitar a adição delas à wiki da equipe. Essa pessoa adiciona as informações por conta própria, mas deixa de realizar uma etapa, resultando em uma interrupção. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Os membros da equipe são capacitados, pois as informações são compartilhadas livremente. 
+  Os novos membros da equipe passam pelo processo de integração mais rapidamente, pois a documentação está atualizada e pode ser pesquisada. 
+  As informações são precisas, levam a ações concretas e são enviadas em tempo hábil. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 O gerenciamento de conhecimento é uma faceta importante das organizações de aprendizagem. Para começar, é necessário ter um repositório central para armazenar seu conhecimento (como um exemplo comum, uma wiki hospedada pela própria empresa). É necessário desenvolver processos para adicionar, atualizar e arquivar conhecimento. Desenvolva padrões para o que deve ser documentado e permita que todos contribuam. 

 **Exemplo de clientes** 

 A Loja UmaEmpresa hospeda uma wiki interna em que todo o conhecimento é armazenado. Os membros da equipe são incentivados a adicionar informações na base de conhecimento à medida que realizam suas tarefas diárias. Trimestralmente, uma equipe multifuncional avalia quais páginas estão mais desatualizadas e determina se elas devem ser arquivadas ou atualizadas. 

 **Etapas da implementação** 

1.  Comece identificando o sistema de gerenciamento de conteúdo em que o conhecimento será armazenado. Obtenha o consentimento das partes interessadas em sua organização. 

   1.  Se você não tiver um sistema de gerenciamento de conteúdo, considere desenvolver uma wiki hospedada pela própria empresa ou usar um repositório de controle de versão como ponto de partida. 

1.  Desenvolva runbooks para adicionar, atualizar e arquivar informações. Instrua a equipe sobre esses processos. 

1.  Identifique quais conhecimentos devem ser armazenados no sistema de gerenciamento de conteúdo. Comece com atividades diárias (runbooks e manuais) que os membros da equipe realizam. Trabalhe com as partes interessadas para priorizar qual conhecimento deve ser adicionado. 

1.  Periodicamente, trabalhe com as partes interessadas para identificar informações desatualizadas e arquive-as ou atualize-as. 

 **Nível de esforço do plano de implementação:** médio. Se você não tiver um sistema de gerenciamento de conteúdo, defina uma wiki hospedada pela própria empresa ou um repositório de documentos com controle de versão. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS11-BP08 Documentar e compartilhar as lições aprendidas](ops_evolve_ops_share_lessons_learned.md) – O gerenciamento de conhecimento facilita o compartilhamento de informações sobre as lições aprendidas. 

 **Documentos relacionados:** 
+ [ Atlassian: gerenciamento do conhecimento ](https://www.atlassian.com/br/itsm/knowledge-management)

 **Exemplos relacionados:** 
+ [ DokuWiki ](https://www.dokuwiki.org/dokuwiki)
+ [ Gollum ](https://github.com/gollum/gollum)
+ [ MediaWiki ](https://www.mediawiki.org/wiki/MediaWiki)
+ [ Wiki.js ](https://github.com/Requarks/wiki)

# OPS11-BP05 Definir motivadores de melhoria
<a name="ops_evolve_ops_drivers_for_imp"></a>

 Identifique os condutores de melhoria para ajudá-lo a avaliar e priorizar as oportunidades. 

 Na AWS, é possível agregar os logs de todas as suas atividades operacionais, workloads e infraestrutura para criar um histórico de atividades detalhado. Assim, é possível usar as ferramentas da AWS para analisar as operações e a integridade da workload ao longo do tempo (por exemplo, identificar tendências, correlacionar eventos e atividades a resultados e comparar e contrastar ambientes e sistemas) para revelar oportunidades de melhoria com base em seus motivadores. 

 Use o CloudTrail para rastrear a atividade da API (por meio do Console de gerenciamento da AWS, da CLI, de SDKs e de APIs) para saber o que está acontecendo nas suas contas. Rastreie as atividades de implantação das ferramentas do desenvolvedor da AWS com o CloudTrail e o CloudWatch. Isso adicionará um histórico detalhado das atividades de suas implantações e seus resultados aos dados de logs do CloudWatch Logs. 

 [Exporte seus dados de log para o Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) para armazenamento de longo prazo. Com o uso do [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc), você descobre e prepara seus dados de log no Amazon S3 para análise. Uso [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc), por meio de sua integração nativa com o AWS Glue, para analisar os dados de logs. Use uma ferramenta de business intelligence, como o [Quick](https://aws.amazon.com/quicksight/) , para visualizar, explorar e analisar os dados. 

 **Antipadrões comuns:** 
+  Você tem um script que funciona, mas não é elegante. Você investe tempo para reescrevê-lo. Agora, ele é uma obra de arte. 
+  Sua startup está tentando obter outro conjunto de financiamento de um capitalista de risco. Ele quer que você demonstre conformidade com o PCI DSS. Você quer deixá-lo contente, então documenta sua conformidade e perde uma data de entrega para um cliente, perdendo esse cliente. Não foi algo errado, mas agora você se pergunta se foi o certo a se fazer. 

 **Benefícios do estabelecimento desta prática recomendada:** Ao determinar os critérios que você deseja implantar para melhorar, é possível minimizar o impacto das motivações baseadas em eventos ou investimentos emocionais. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Compreender as motivações para melhoria: só faça alterações em um sistema quando o resultado desejado for suportado. 
  +  Capacidades desejadas: avalie as capacidades e os recursos desejados ao avaliar oportunidades de melhoria. 
    +  [Novidades da AWS](https://aws.amazon.com/new/) 
  +  Problemas inaceitáveis: avalie problemas, bugs e vulnerabilidades inaceitáveis ao avaliar oportunidades de melhoria. 
    +  [Boletins de segurança mais recentes da AWS](https://aws.amazon.com/security/security-bulletins/) 
    +  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
  +  Requisitos de conformidade: avalie as atualizações e alterações necessárias para manter a conformidade com a regulamentação e com a política, ou para permanecer sob o suporte de terceiros ao analisar as oportunidades de melhoria. 
    +  [Conformidade da AWS](https://aws.amazon.com/compliance/) 
    +  [Programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/) 
    +  [Notícias recentes sobre conformidade da AWS](https://aws.amazon.com/compliance/compliance-latest-news/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) 
+  [Quick](https://aws.amazon.com/quicksight/) 
+  [Conformidade da AWS](https://aws.amazon.com/compliance/) 
+  [Notícias recentes sobre conformidade da AWS](https://aws.amazon.com/compliance/compliance-latest-news/) 
+  [Programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/) 
+  [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) 
+  [Boletins de segurança mais recentes da AWS](https://aws.amazon.com/security/security-bulletins/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [Exporte seus dados de log para o Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 
+  [Novidades da AWS](https://aws.amazon.com/new/) 

# OPS11-BP06 Validar insights
<a name="ops_evolve_ops_validate_insights"></a>

 Revise os resultados e as respostas da análise com equipes multifuncionais e proprietários de negócios. Use essas revisões para estabelecer um entendimento comum, identificar impactos adicionais e determinar cursos de ação. Ajuste as respostas conforme apropriado. 

 **Antipadrões comuns:** 
+  Você vê que a utilização da CPU está em 95% em um sistema e prioriza encontrar uma maneira de reduzir a carga no sistema. Você determina que a melhor ação é expandir. O sistema é um transcodificador e foi dimensionado para ser executado com 95% de utilização da CPU o tempo todo. O proprietário do sistema poderia ter explicado a situação se você tivesse entrado em contato com ele. Seu tempo foi perdido. 
+  Um proprietário do sistema sustenta que o sistema é de missão crítica. O sistema não foi colocado em um ambiente de alta segurança. Para melhorar a segurança, você implementa os controles de detecção e prevenção adicionais necessários para sistemas de missão crítica. Você notifica o proprietário do sistema de que o trabalho foi concluído e que ele será cobrado pelos recursos adicionais. Na discussão após essa notificação, o proprietário do sistema aprende que há uma definição formal para sistemas de missão crítica que o sistema dele não atende. 

 **Benefícios do estabelecimento desta prática recomendada:** Ao validar insights com proprietários de empresas e especialistas no assunto, você pode estabelecer um entendimento comum e orientar de maneira mais eficaz a melhoria. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Validar insights: envolva-se com proprietários de empresas e especialistas no assunto para garantir que haja entendimento e concordância comuns sobre o significado dos dados coletados. Identifique preocupações adicionais, possíveis impactos e determine as ações. 

# OPS11-BP07 Fazer análises das métricas de operações
<a name="ops_evolve_ops_metrics_review"></a>

 Realize regularmente análises retrospectivas das métricas de operações com participantes de equipes cruzadas de diferentes áreas do negócio. Use essas análises para identificar oportunidades de melhorias e possíveis ações e compartilhar as lições aprendidas. 

 Procure oportunidades para melhorar em todos os seus ambientes (por exemplo, desenvolvimento, teste e produção). 

 **Antipadrões comuns:** 
+  Houve uma promoção de varejo significativa que foi interrompida por sua janela de manutenção. A empresa continua sem saber que existe uma janela de manutenção padrão que pode ser atrasada se houver outros eventos que afetam os negócios. 
+  Você sofreu uma interrupção prolongada devido ao uso de uma biblioteca com bugs geralmente utilizada em sua organização. Desde então, você migrou para uma biblioteca confiável. As outras equipes da organização não sabem que estão em risco. Se você se reunisse regularmente e analisasse esse incidente, eles ficariam conscientes do risco. 
+  A performance do transcodificador tem diminuído constantemente e está afetando a equipe de mídia. Ainda não é algo terrível. Você não terá a oportunidade de descobrir até que seja ruim o suficiente para causar um incidente. Se você analisasse as métricas de operações com a equipe de mídia, haveria uma oportunidade para que a mudança nas métricas e a experiência deles fossem reconhecidas e o problema fosse resolvido. 
+  Você não está analisando a satisfação dos SLAs do cliente. Você está tendendo a não cumprir os SLAs de seus clientes. Há penalidades financeiras relacionadas ao não cumprimento de SLAs dos clientes. Se você se reunisse regularmente para analisar as métricas desses SLAs, teria a oportunidade de reconhecer e resolver o problema. 

 **Benefícios do estabelecimento desta prática recomendada:** Ao realizar reuniões regularmente para analisar métricas, eventos e incidentes de operações, você mantém um entendimento comum entre as equipes, compartilha as lições aprendidas e pode priorizar e direcionar melhorias. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Análises das métricas das operações: execute regularmente análises retrospectivas das métricas de operações com participantes de equipes de diferentes áreas do negócio. Envolva as partes interessadas, incluindo as equipes de negócios, desenvolvimento e operações, para validar suas descobertas de feedback imediato e análise retrospectiva e para compartilhar as lições aprendidas. Use suas ideias para identificar oportunidades de melhoria e possíveis cursos de ação. 
  +  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 
  +  [Uso de métricas do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
  +  [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
  +  [Referência de métricas e de dimensões do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [Referência de métricas e de dimensões do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
+  [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Uso de métricas do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 

# OPS11-BP08 Documentar e compartilhar as lições aprendidas
<a name="ops_evolve_ops_share_lessons_learned"></a>

 Documente e compartilhe as lições aprendidas das atividades operacionais, para que possa usá-las internamente e entre equipes. 

 Você deve compartilhar o que suas equipes aprendem para aumentar os benefícios em toda a organização. Você desejará compartilhar informações e recursos para evitar erros que podem ser evitados e facilitar os esforços de desenvolvimento. isso permitirá que você se concentre no fornecimento dos recursos desejados. 

 Use o AWS Identity and Access Management (IAM) para definir permissões que permitem acesso controlado aos recursos que você deseja compartilhar dentro e entre contas. Você deve usar os repositórios do AWS CodeCommit com controle de versão para compartilhar bibliotecas de aplicativos, procedimentos com script, documentações de procedimentos e outras documentações do sistema. Compartilhe seus padrões de computação partilhando o acesso às suas AMIs e autorizando o uso de suas funções do Lambda entre contas. Você também deve compartilhar seus padrões de infraestrutura como modelos do AWS CloudFormation. 

 Por meio de APIs e SDKs da AWS, é possível integrar ferramentas e repositórios externos e de terceiros (por exemplo, GitHub, BitBucket e SourceForge). Ao compartilhar o que você aprendeu e desenvolveu, tenha cuidado para estruturar as permissões para garantir a integridade dos repositórios compartilhados. 

 **Antipadrões comuns:** 
+  Você sofreu uma interrupção prolongada devido ao uso de uma biblioteca com bugs geralmente utilizada em sua organização. Desde então, você migrou para uma biblioteca confiável. As outras equipes em sua organização não sabem que estão em risco. Se você documentasse e compartilhasse sua experiência com essa biblioteca, eles ficariam cientes do risco. 
+  Você identificou um caso de borda em um microsserviço compartilhado internamente que causa a queda das sessões. Você atualizou suas chamadas para o serviço para evitar esse caso extremo. As outras equipes da organização não sabem que estão em risco. Se você documentasse e compartilhasse sua experiência com essa biblioteca, eles ficariam cientes do risco. 
+  Você encontrou uma maneira de reduzir significativamente os requisitos de utilização da CPU para um dos seus microsserviços. Você não sabe se alguma outra equipe poderia aproveitar essa técnica. Se você documentasse e compartilhasse sua experiência com essa biblioteca, eles teriam a oportunidade de aproveitá-la. 

 **Benefícios do estabelecimento desta prática recomendada:** Compartilhe as lições aprendidas para apoiar melhorias e maximizar os benefícios da experiência. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Documentar e compartilhar as lições aprendidas: tenha procedimentos para documentar as lições aprendidas com a execução de atividades operacionais e análises retrospectivas, para que possam ser usadas por outras equipes. 
  +  Compartilhar lições aprendidas: tenha procedimentos para compartilhar as lições aprendidas e os artefatos associados entre as equipes. Por exemplo, compartilhe procedimentos atualizados, orientações, governança e práticas recomendadas por meio de um wiki acessível. Compartilhe scripts, códigos e bibliotecas por meio de um repositório comum. 
    +  [Delegação de acesso ao ambiente da AWS](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s) 
    +  [Compartilhar um repositório do AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html) 
    +  [Fácil autorização das funções do AWS Lambda](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/) 
    +  [Compartilhamento de uma AMI com contas específicas da AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) 
    +  [Acelerar o compartilhamento de modelos com uma URL do designer do AWS CloudFormation](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/) 
    +  [Usar o AWS Lambda com o Amazon SNS](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Fácil autorização das funções do AWS Lambda](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/) 
+  [Compartilhar um repositório do AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html) 
+  [Compartilhamento de uma AMI com contas específicas da AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) 
+  [Acelerar o compartilhamento de modelos com uma URL do designer do AWS CloudFormation](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/) 
+  [Usar o AWS Lambda com o Amazon SNS](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html) 

 **Vídeos relacionados:** 
+  [Delegação de acesso ao ambiente da AWS](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s) 

# OPS11-BP09 Alocar tempo para fazer melhorias
<a name="ops_evolve_ops_allocate_time_for_imp"></a>

 Dedique tempo e recursos em seus processos para possibilitar melhorias incrementais contínuas. 

 Na AWS, é possível criar duplicatas temporárias de ambientes, reduzindo o risco, o esforço e o custo da experimentação e dos testes. Esses ambientes duplicados podem ser usados para testar as conclusões de sua análise, experimentar e desenvolver e testar as melhorias planejadas. 

 **Antipadrões comuns:** 
+  Há um problema de performance conhecido no servidor de aplicativos. Ele é adicionado ao backlog por trás de cada implementação de recurso planejada. Se a taxa de adição de recursos planejados permanecer constante, o problema de performance nunca será resolvido. 
+  Para oferecer suporte à melhoria contínua, você aprova administradores e desenvolvedores usando todo o tempo extra para selecionar e implementar melhorias. Nenhuma melhoria é concluída. 

 **Benefícios do estabelecimento desta prática recomendada:** Ao dedicar tempo e recursos em seus processos, você possibilita melhorias incrementais contínuas. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Alocar tempo para fazer melhorias: dedique tempo e recursos em seus processos para possibilitar melhorias incrementais contínuas. Implemente alterações para melhorar e avaliar os resultados para determinar o sucesso. Se os resultados não satisfizerem as metas e a melhoria ainda for uma prioridade, siga cursos de ação alternativos. 

# Segurança
<a name="a-security"></a>

O pilar Segurança refere-se à capacidade de proteger dados, sistemas e ativos para utilizar as tecnologias de nuvem para melhorar sua segurança. Você pode encontrar orientações prescritivas sobre implementação no [whitepaper Pilar de segurança](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html?ref=wellarchitected-wp). 

**Topics**
+ [Fundamentos de segurança](a-sec-security.md)
+ [Gerenciamento de identidade e acesso](a-identity-and-access-management.md)
+ [Detecção](a-detective-controls.md)
+ [Proteção de infraestrutura](a-infrastructure-protection.md)
+ [Proteção de dados](a-data-protection.md)
+ [Resposta a incidentes](a-incident-response.md)
+ [Segurança de aplicações](a-appsec.md)

# Fundamentos de segurança
<a name="a-sec-security"></a>

**Topics**
+ [SEGURANÇA 1. Como operar com segurança sua workload?](sec-01.md)

# SEGURANÇA 1. Como operar com segurança sua workload?
<a name="sec-01"></a>

 Para operar sua workload com segurança, você deve aplicar as práticas recomendadas gerais a todas as áreas de segurança. Use os requisitos e os processos que você definiu em excelência operacional em nível de carga de trabalho e também organizacional e aplique-os a todas as áreas. Manter-se atualizado com as recomendações da AWS e do setor e a inteligência de ameaças ajuda você a desenvolver seu modelo de ameaças e objetivos de controle. A automação de processos, testes e validação de segurança permite que você escale suas operações de segurança. 

**Topics**
+ [SEC01-BP01 Separar as workloads usando contas](sec_securely_operate_multi_accounts.md)
+ [SEC01-BP02 Proteger as propriedades e o usuário raiz das contas](sec_securely_operate_aws_account.md)
+ [SEC01-BP03 Identificar e validar objetivos de controle](sec_securely_operate_control_objectives.md)
+ [SEC01-BP04 Manter-se atualizado sobre as ameaças à segurança](sec_securely_operate_updated_threats.md)
+ [SEC01-BP05 Manter-se atualizado com as recomendações de segurança](sec_securely_operate_updated_recommendations.md)
+ [SEC01-BP06 Automatizar testes e validação de controles de segurança em pipelines](sec_securely_operate_test_validate_pipeline.md)
+ [SEC01-BP07 Identificar ameaças e priorizar mitigações com o uso de um modelo de ameaça](sec_securely_operate_threat_model.md)
+ [SEC01-BP08 Avaliar e implementar regularmente novos serviços e recursos de segurança](sec_securely_operate_implement_services_features.md)

# SEC01-BP01 Separar as workloads usando contas
<a name="sec_securely_operate_multi_accounts"></a>

 Estabeleça barreiras de proteção e isolamento entre workloads e ambientes (como de produção, desenvolvimento e teste) por meio de uma estratégia de várias contas. A separação em nível de conta é altamente recomendável, pois ela oferece um limite de isolamento robusto para segurança, faturamento e acesso. 

**Resultado desejado:** uma estrutura de conta que isola operações na nuvem, workloads não relacionadas e ambientes em contas separadas, aumentando a segurança em toda a infraestrutura de nuvem.

**Antipadrões comuns:**
+  Colocação de várias workloads não relacionadas com diferentes níveis de confidencialidade na mesma conta.
+  Estrutura de unidade organizacional (UO) definida de forma inadequada.

**Benefícios do estabelecimento desta prática recomendada:**
+  Redução do escopo de impacto se uma workload for acessada acidentalmente.
+  Governança central de acesso a serviços, recursos e regiões da AWS.
+  Manutenção da segurança da infraestrutura de nuvem com políticas e administração centralizada de serviços de segurança.
+  Criação de contas automatizada e processo de manutenção.
+  Auditoria centralizada da infraestrutura de conformidade e requisitos regulatórios.

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 As Contas da AWS oferecem um limite de isolamento de segurança entre workloads ou recursos que operam em diferentes níveis de confidencialidade. Para utilizar esse limite de isolamento, a AWS oferece ferramentas para gerenciar em grande escala suas workloads de nuvem por meio de uma estratégia de várias contas. Para ter orientações sobre os conceitos, os padrões e a implementação de uma estratégia de várias contas na AWS, consulte [Organizar seu ambiente da AWS com o uso de várias contas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html). 

 Quando você tem várias Contas da AWS no gerenciamento central, elas devem ser organizadas em uma hierarquia definida por camadas de unidades organizacionais (UOs). Desse modo, os controles de segurança podem ser organizados e aplicados às UOs e às contas membros, estabelecendo controles preventivos consistentes nas contas membros da organização. Os controles de segurança são herdados, permitindo que você filtre as permissões disponíveis para as contas membros localizadas em níveis inferiores de uma hierarquia de UOs. Um bom design aproveita essa herança para reduzir o número e a complexidade das políticas de segurança necessárias para obter os controles de segurança desejados para cada conta membro. 

 O [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) e o [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) são dois serviços que você pode utilizar para implementar e gerenciar essa estrutura de várias contas em seu ambiente da AWS. O AWS Organizations possibilita organizar as contas em uma hierarquia definida por uma ou mais camadas de UOs, em que cada UO contém uma série de contas membros. As [políticas de controle de serviços](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) permitem que o administrador da organização estabeleça controles preventivos detalhados nas contas membros, e o [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html) pode ser utilizado para estabelecer controles proativos e de detecção nessas contas. Muitos serviços da AWS [integram-se ao AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html) para oferecer controles administrativos delegados e realizar tarefas específicas do serviço em todas as contas membros da organização. 

 Estruturado sobre o AWS Organizations, o [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) oferece práticas recomendadas de um clique para um ambiente da AWS de várias contas com uma [zona de pouso](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html). A zona de pouso é o ponto de entrada para o ambiente de várias contas estabelecido pelo Control Tower. O Control Tower oferece vários [benefícios](https://aws.amazon.com/blogs/architecture/fast-and-secure-account-governance-with-customizations-for-aws-control-tower/) em comparação com o AWS Organizations. Três benefícios que oferecem governança aprimorada de contas são: 
+  Barreiras de proteção de segurança obrigatórias e integradas que são aplicadas automaticamente às contas admitidas na organização. 
+  Barreiras de proteção opcionais que podem ser ativadas ou desativadas em determinado conjunto de UOs. 
+  O [AWS Control Tower Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) oferece implantação automatizada de contas que contêm linhas de base aprovadas e opções de configuração em sua organização. 

## Etapas da implementação
<a name="implementation-steps"></a>

1.  **Projetar uma estrutura de unidade organizacional:** uma estrutura de unidade organizacional projetada adequadamente reduz o trabalho de gerenciamento necessário para criar e manter políticas de controle de serviços e outros controles de segurança. Sua estrutura de unidade organizacional deve estar [alinhada com as necessidades, a confidencialidade dos dados e a estrutura de workload de sua empresa](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/). 

1.  **Criar uma zona de pouso para seu ambiente de várias contas:** uma zona de pouso oferece uma base consistente de infraestrutura e segurança na qual sua organização pode desenvolver, executar e implantar workloads com rapidez. É possível usar uma [zona de pouso personalizada ou o AWS Control Tower](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/building-landing-zones.html) para orquestrar seu ambiente. 

1.  **Estabelecer barreiras de proteção:** implemente barreiras de proteção consistentes para seu ambiente por meio da zona de pouso. O AWS Control Tower oferece uma lista de controles [obrigatórios](https://docs.aws.amazon.com/controltower/latest/userguide/mandatory-controls.html) e [opcionais](https://docs.aws.amazon.com/controltower/latest/userguide/optional-controls.html) que podem ser implantados. Os controles obrigatórios são implantados automaticamente na implementação do Control Tower. Leia a lista de controles opcionais e altamente recomendados e implemente controles adequados às suas necessidades. 

1.  **Restringir o acesso a regiões adicionadas recentemente**: para novas Regiões da AWS, recursos do IAM, como usuários e perfis, serão propagados somente para as regiões especificadas. Essa ação pode ser realizada por meio do [console ao usar o Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html) ou ajustando as políticas de permissões do [IAM no AWS Organizations](https://aws.amazon.com/blogs/security/setting-permissions-to-enable-accounts-for-upcoming-aws-regions/). 

1.  **Considerar o AWS [CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)**: o StackSets ajuda você a implantar recursos, como grupos, políticas e perfis do IAM em diferentes regiões e Contas da AWS por meio de um modelo aprovado. 

## Recursos
<a name="resources"></a>

**Práticas recomendadas relacionadas:** 
+ [SEC02-BP04 Contar com um provedor de identidades centralizado](sec_identities_identity_provider.md)

**Documentos relacionados:** 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 
+  [Diretrizes de auditoria de segurança da AWS](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+  [Práticas recomendadas do IAM](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html) 
+  [Usar o CloudFormation StackSets para fornecer recursos entre várias regiões e Contas da AWS](https://aws.amazon.com/blogs/aws/use-cloudformation-stacksets-to-provision-resources-across-multiple-aws-accounts-and-regions/) 
+  [Perguntas frequentes sobre o Organizations](https://aws.amazon.com/organizations/faqs/) 
+  [Terminologia e conceitos do AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) 
+  [Práticas recomendadas para políticas de controle de serviços do AWS Organizations em um ambiente de várias contas](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/) 
+  [Guia de referência de gerenciamento de contas da AWS](https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html) 
+  [Organização do ambiente usando várias contas da AWS](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 

**Vídeos relacionados:** 
+  [Habilitar a adoção da AWS em grande escala com automação e governança](https://youtu.be/GUMSgdB-l6s) 
+  [Práticas recomendadas de segurança de acordo com o Well-Architected](https://youtu.be/u6BCVkXkPnM) 
+  [Criar e administrar várias contas com o uso do AWS Control Tower](https://www.youtube.com/watch?v=agpyuvRv5oo) 
+  [Habilitar o Control Tower para organizações existentes](https://www.youtube.com/watch?v=CwRy0t8nfgM) 

**Workshops relacionados:** 
+  [Dia de imersão no Control Tower](https://controltower.aws-management.tools/immersionday/) 

# SEC01-BP02 Proteger as propriedades e o usuário raiz das contas
<a name="sec_securely_operate_aws_account"></a>

 O usuário raiz é o mais privilegiado de uma Conta da AWS, com acesso administrativo integral a todos os recursos da conta, e em alguns casos não pode ser restringido por políticas de segurança. Desabilitar o acesso programático ao usuário raiz, estabelecer controles apropriados para ele e evitar o uso rotineiro desse usuário ajuda a reduzir o risco de exposição acidental das credenciais raiz e o subsequente comprometimento do ambiente de nuvem. 

**Resultado desejado: **proteger o usuário raiz ajuda a reduzir a chance de danos acidentais ou intencionais decorrentes do mau uso das respectivas credenciais. Estabelecer controles de detecção também pode alertar o pessoal apropriado quando se realizam ações utilizando o usuário raiz.

**Antipadrões comuns:**
+  Utilizar o usuário raiz para outras tarefas que não sejam aquelas que exigem credenciais do usuário raiz.  
+  Negligenciar os testes dos planos de contingência regularmente a fim de verificar a funcionalidade da infraestrutura, dos processos e dos funcionários essenciais durante uma emergência. 
+  Considerar apenas o fluxo típico de login de contas e não considerar nem testar métodos de recuperação de contas alternativos. 
+  Não lidar com DNS, servidores de e-mail e operadoras de telefonia como parte do perímetro de segurança essencial, pois eles são usados no fluxo de recuperação de contas. 

 **Benefícios do estabelecimento desta prática recomendada:** proteger o acesso ao usuário raiz cria a confiança de que as ações em sua conta estão controladas e auditadas. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 A AWS oferece muitas ferramentas para ajudar a proteger sua conta. No entanto, como algumas dessas medidas não estão habilitadas por padrão, é necessário implementá-las diretamente. Leve em consideração essas recomendações como etapas fundamentais para proteger sua Conta da AWS. Ao implementar essas etapas, é importante criar um processo para avaliar e monitorar os controles de segurança de forma contínua. 

 Ao criar uma Conta da AWS pela primeira vez, você começa com uma identidade que tem acesso completo a todos os recursos e serviços da AWS na conta. Essa identidade é chamada de usuário raiz da Conta da AWS. É possível fazer login como usuário raiz usando o endereço de e-mail e a senha utilizados para criar a conta. Devido ao acesso elevado concedido ao usuário raiz da AWS, é necessário limitar o uso do usuário raiz da AWS à realização de tarefas que [o exijam especificamente](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html). As credenciais de login do usuário raiz devem ser bem protegidas, e a autenticação multifator (MFA) sempre deve ser habilitada para o usuário raiz da Conta da AWS. 

 Além do fluxo de autenticação normal para fazer login com seu usuário raiz usando um nome de usuário, senha e o dispositivo de autenticação multifator (MFA), há fluxos de recuperação de contas para fazer login com seu usuário raiz da Conta da AWS com o endereço de e-mail e o número de telefone associados à sua conta. Dessa forma, é igualmente importante proteger a conta de e-mail do usuário raiz para a qual o e-mail de recuperação é enviado e o número de telefone associado à conta. Além disso, considere possíveis dependências circulares em que o endereço de e-mail associado ao usuário raiz é hospedado em servidores de e-mail ou recursos de serviço de nome de domínio (DNS) da mesma Conta da AWS. 

 Ao usar o AWS Organizations, há várias Contas da AWS, e cada uma tem um usuário raiz. Uma conta é designada como a conta de gerenciamento e várias camadas de contas membros podem ser adicionadas à conta de gerenciamento. Priorize a proteção do usuário raiz de sua conta de gerenciamento e, depois, os usuários raiz das contas membros. A estratégia para proteger o usuário raiz de sua conta de gerenciamento pode diferir da utilizada nos usuários raiz de suas contas membros, e é possível implementar controles de segurança preventivos nos usuários raiz dessas contas. 

### Etapas da implementação
<a name="implementation-steps"></a>

 As etapas de implementação a seguir são recomendadas para estabelecer controles para o usuário raiz. Quando aplicável, as recomendações têm referências cruzadas com o [Benchmark do CIS AWS Foundations versão 1.4.0](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls-1.4.0.html). Além dessas etapas, consulte as [Diretrizes de práticas recomendadas da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) para proteger os recursos e a Conta da AWS. 

 **Controles preventivos** 

1.  Configure [informações de contato](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html) precisos para a conta. 

   1.  Essas informações são usadas para o fluxo de recuperação de senha perdida, o fluxo de recuperação de conta de dispositivo MFA perdida e para comunicações com sua equipe sobre segurança crítica. 

   1.  Utilize um endereço de e-mail hospedado por seu domínio corporativo, preferencialmente uma lista de distribuição, como o endereço de e-mail do usuário raiz. O uso de uma lista de distribuição em vez da conta de e-mail de um indivíduo oferece redundância e continuidade adicionais para o acesso à conta raiz por longos períodos. 

   1.  O número de telefone listado nas informações de contato deve ser um telefone dedicado e seguro para esse fim. O número de telefone não deve ser listado nem compartilhado com ninguém. 

1.  Não crie chaves de acesso para o usuário raiz. Se houver chaves de acesso, remova-as (CIS 1.4). 

   1.  Elimine todas as credenciais programáticas de longa duração (chaves de acesso e secretas) para o usuário raiz. 

   1.  Se já houver chaves de acesso do usuário raiz, será necessário fazer a transição dos processos que utilizam essas chaves para utilizar chaves de acesso temporárias de um perfil do AWS Identity and Access Management (IAM), depois [excluir as chaves de acesso do usuário raiz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-access-key.html#root-user-delete-access-key). 

1.  Determine se você precisa armazenar credenciais para o usuário raiz. 

   1.  Ao usar o AWS Organizations para criar contas membros, a senha inicial do usuário raiz em novas contas membros é definida como um valor aleatório que não é exposto a você. Se necessário, considere utilizar o fluxo de redefinição de senha de sua conta de gerenciamento do AWS Organizations para [obter acesso à conta membro](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_access-as-root). 

   1.  Para Contas da AWS autônomas ou a conta de gerenciamento do AWS Organizations, considere criar e armazenar de forma segura as credenciais do usuário raiz. Ativar a MFA para o usuário raiz 

1.  Ative os controles preventivos para os usuários raiz das contas membros em ambientes de várias contas da AWS. 

   1.  Considere habilitar a barreira de proteção preventiva [Desautorizar criação de chaves de acesso raiz para o usuário raiz](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-access-keys) para contas membros. 

   1.  Considere habilitar a barreira de proteção preventiva [Desautorizar criação como um usuário raiz](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-auser-actions) para contas membros. 

1.  Se você precisar de credenciais para o usuário raiz: 

   1.  Use uma senha complexa. 

   1.  Ative a autenticação multifator (MFA) para o usuário raiz, especialmente para contas (pagantes) de gerenciamento do AWS Organizations (CIS 1.5). 

   1.  Considere o uso de dispositivos de MFA de hardware para ter resiliência e segurança, pois os dispositivos de uso único reduzem as chances de os dispositivos que contêm seus códigos de MFA serem reutilizados para outros fins. Garanta que os dispositivos de MFA de hardware alimentados por bateria sejam substituídos regularmente. (CIS 1.6) 
      +  Para configurar a MFA para o usuário raiz, siga as instruções para habilitar uma [MFA virtual](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_mfa_enable_virtual.html#enable-virt-mfa-for-root) ou um [dispositivo de MFA de hardware](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_mfa_enable_physical.html#enable-hw-mfa-for-root). 

   1.  Considere registrar vários dispositivos de MFA para backup. [Até oito dispositivos de MFA são permitidos por conta](https://aws.amazon.com/blogs/security/you-can-now-assign-multiple-mfa-devices-in-iam/). 
      +  Registrar mais de um dispositivo de MFA para o usuário raiz desabilita automaticamente o [fluxo para recuperar sua conta se o dispositivo de MFA for perdido](https://aws.amazon.com/premiumsupport/knowledge-center/reset-root-user-mfa/). 

   1.  Armazene a senha com segurança e considere as dependências circulares se for armazenar a senha eletronicamente. Não armazene a senha de uma forma que exija o acesso à mesma Conta da AWS para obtê-la. 

1.  Opcional: considere estabelecer um cronograma de alternância de senha periódica para o usuário raiz. 
   +  As práticas recomendadas de gerenciamento de credenciais dependem de seus requisitos regulatórios e de política. Os usuários raiz protegidos por MFA não dependem da senha como um único fator de autenticação. 
   +  [A alteração periódica da senha de usuário raiz](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_passwords_change-root.html) reduz o risco de mau uso de uma senha exposta acidentalmente. 

### Controles de detecção
<a name="detective-controls"></a>
+  Crie alarmes para detectar o uso das credenciais raiz (CIS 1.7). [Quando habilitado, o Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html) monitora e alerta o uso de credenciais da API do usuário raiz por meio da descoberta [RootCredentialUsage](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage). 
+  Avalie e implemente os controles de detecção incluídos no [pacote de conformidade do Pilar de segurança do AWS Well-Architected para AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-wa-Security-Pillar.html) ou, se usar o AWS Control Tower, os [controles altamente recomendados](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html) disponíveis no Control Tower. 

### Orientação operacional
<a name="operational-guidance"></a>
+  Determine quem na organização deve ter acesso às credenciais do usuário raiz. 
  +  Use uma regra de duas pessoas de forma que um indivíduo tenha acesso a todas as credenciais necessárias e MFA para obter acesso de usuário raiz. 
  +  Verifique se é a organização, e não um único indivíduo, que mantém controle sobre o número de telefone e alias de e-mail associados à conta (que são utilizados para redefinição de senha e fluxo de redefinição de MFA). 
+  Utilize o usuário raiz apenas como uma exceção (CIS 1.7). 
  +  O usuário raiz da AWS não deve ser usado para tarefas diárias, mesmo que sejam tarefas administrativas. Somente faça login como usuário raiz para realizar [tarefas da AWS que o exijam especificamente](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html). Todas as outras ações devem ser realizadas por outros usuários que assumem perfis apropriados. 
+  Confira periodicamente se o acesso ao usuário raiz está funcionando de forma que os procedimentos sejam testados antes de uma situação de emergência que exija o uso das credenciais do usuário raiz. 
+  Confira periodicamente se o endereço de e-mail associado à conta e os listados em [Contatos alternativos](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html) funcionam. Monitore as caixas de entrada de e-mail das quais você recebe notificações de segurança abuse@amazon.com. Além disso, garanta que todos os números de telefone associados à conta estejam funcionando. 
+  Prepare um procedimento de resposta a incidentes para responder ao mau uso da conta raiz. Consulte o [Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) e as práticas recomendadas na [seção “Resposta a incidentes” do whitepaper Pilar Segurança](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) para ter mais informações sobre como criar uma estratégia de resposta a incidentes para sua Conta da AWS. 

## Recursos
<a name="resources"></a>

**Práticas recomendadas relacionadas:** 
+ [SEC01-BP01 Separar as workloads usando contas](sec_securely_operate_multi_accounts.md)
+ [SEC02-BP01 Usar mecanismos de login fortes](sec_identities_enforce_mechanisms.md)
+ [SEC03-BP02 Conceder acesso com privilégio mínimo](sec_permissions_least_privileges.md)
+ [SEC03-BP03 Estabelecer processo de acesso de emergência](sec_permissions_emergency_process.md)
+ [SEC10-BP05 Acesso pré-provisionado](sec_incident_response_pre_provision_access.md)

**Documentos relacionados:** 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 
+  [Diretrizes de auditoria de segurança da AWS](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+  [Práticas recomendadas do IAM](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html) 
+  [Amazon GuardDuty: alerta de uso de credenciais raiz](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage) 
+  [Orientações passo a passo sobre como monitorar o uso de credenciais raiz por meio do CloudTrail](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls-1.4.0.html#securityhub-cis1.4-controls-1.7) 
+  [Tokens de MFA aprovados para uso com a AWS](https://aws.amazon.com/iam/features/mfa/) 
+  Implementar [o acesso de quebra de vidro](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) na AWS 
+  [Os dez principais itens de segurança para aprimorar sua Conta da AWS](https://aws.amazon.com/blogs/security/top-10-security-items-to-improve-in-your-aws-account/) 
+  [O que fazer se eu notar atividade não autorizada em minha Conta da AWS?](https://aws.amazon.com/premiumsupport/knowledge-center/potential-account-compromise/) 

**Vídeos relacionados:** 
+  [Habilitar a adoção da AWS em grande escala com automação e governança](https://youtu.be/GUMSgdB-l6s) 
+  [Práticas recomendadas de segurança de acordo com o Well-Architected](https://youtu.be/u6BCVkXkPnM) 
+  [Limitar o uso de credenciais raiz da AWS](https://youtu.be/SMjvtxXOXdU?t=979) do AWS re:inforce 2022: Práticas recomendadas de segurança com o AWS IAM

**Exemplos e laboratórios relacionados:** 
+  [Laboratório: Conta da AWS e usuário raiz](https://www.wellarchitectedlabs.com/security/100_labs/100_aws_account_and_root_user/) 

# SEC01-BP03 Identificar e validar objetivos de controle
<a name="sec_securely_operate_control_objectives"></a>

 Com base em seus requisitos de conformidade e riscos identificados no modelo de ameaça, derive e valide os objetivos de controle e os controles que você precisa aplicar à carga de trabalho. A validação contínua de objetivos de controle e controles ajuda a medir a eficácia da mitigação de riscos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Identificar requisitos de conformidade: descubra os requisitos organizacionais, legais e de conformidade que a sua workload precisa cumprir. 
+  Identificar recursos de conformidade da AWS: identifique os recursos da AWS disponíveis para ajudar você com a conformidade. 
  +  [https://aws.amazon.com/compliance/ ](https://aws.amazon.com/compliance/)
  + [ https://aws.amazon.com/artifact/](https://aws.amazon.com/artifact/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Security Audit Guidelines (Diretrizes de auditoria de segurança da AWS)](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+ [ Boletins de segurança](https://aws.amazon.com/security/security-bulletins/) 

 **Vídeos relacionados:** 
+  [AWS Security Hub CSPM: Manage Security Alerts and Automate Compliance (AWS Security Hub: gerenciamento de alertas de segurança e automatização da governança)](https://youtu.be/HsWtPG_rTak) 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP04 Manter-se atualizado sobre as ameaças à segurança
<a name="sec_securely_operate_updated_threats"></a>

 Para ajudar a definir e implementar os controles apropriados, reconheça vetores de ataque mantendo-se a par das ameaças de segurança mais recentes. Consuma o AWS Managed Services para facilitar o recebimento de notificações de comportamentos inesperados ou incomuns em suas contas da AWS. Investigue usando ferramentas de parceiros da AWS ou feeds de informações sobre ameaças de terceiros como parte de seu fluxo de informações de segurança. A [lista de vulnerabilidades e exposições comuns (CVEs) ](https://cve.mitre.org/) contém vulnerabilidades de segurança cibernética divulgadas publicamente que você pode usar para se manter atualizado. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Inscreva-se em fontes de inteligência de ameaças: analise regularmente as informações de inteligência de ameaças de várias fontes relevantes sobre as tecnologias usadas na sua workload. 
  +  [Lista de vulnerabilidades e exposições comuns ](https://cve.mitre.org/)
+  Considerar [AWS Shield Advanced](https://aws.amazon.com/shield/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) : oferece visibilidade quase em tempo real das fontes de inteligência, se sua workload for acessível pela Internet. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Security Audit Guidelines (Diretrizes de auditoria de segurança da AWS)](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+  [AWS Shield](https://aws.amazon.com/shield/) 
+ [ Boletins de segurança](https://aws.amazon.com/security/security-bulletins/) 

 **Vídeos relacionados:** 
+ [Security Best Practices the Well-Architected Way ](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP05 Manter-se atualizado com as recomendações de segurança
<a name="sec_securely_operate_updated_recommendations"></a>

 Mantenha-se atualizado com as recomendações de segurança da AWS e do setor para evoluir a postura de segurança de sua workload. [Boletins de segurança da AWS](https://aws.amazon.com/security/security-bulletins/?card-body.sort-by=item.additionalFields.bulletinDateSort&card-body.sort-order=desc&awsf.bulletins-year=year%232009) contêm informações importantes sobre notificações de segurança e privacidade. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Siga as atualizações da AWS: inscreva-se ou verifique regularmente novas recomendações e dicas. 
  +  [Laboratórios do AWS Well-Architected](https://wellarchitectedlabs.com/?ref=wellarchitected) 
  +  [Blog de segurança da AWS](https://aws.amazon.com/blogs/security/?ref=wellarchitected) 
  +  [Documentação do serviço da AWS](https://aws.amazon.com/documentation/?ref=wellarchitected) 
+  Inscreva-se para receber as novidades do setor: consulte regularmente os feeds de notícias de várias fontes relevantes às tecnologias usadas na sua workload. 
  +  [Exemplo: lista de vulnerabilidade e exposições comuns](https://cve.mitre.org/cve/?ref=wellarchitected) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Boletins de segurança](https://aws.amazon.com/security/security-bulletins/) 

 **Vídeos relacionados:** 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP06 Automatizar testes e validação de controles de segurança em pipelines
<a name="sec_securely_operate_test_validate_pipeline"></a>

 Estabeleça linhas de base e modelos seguros para mecanismos de segurança que são testados e validados como parte de sua compilação, pipelines e processos. Use ferramentas e automação para testar e validar todos os controles de segurança continuamente. Por exemplo, verifique itens, como imagens de máquina e modelos de infraestrutura como código, para detectar vulnerabilidades de segurança, irregularidades e desvios da uma linha de base estabelecida em cada estágio. O AWS CloudFormation Guard pode ajudar você a verificar se os modelos do CloudFormation são seguros, economizar tempo e reduzir o risco de erro de configuração. 

É fundamental reduzir o número de configurações incorretas de segurança introduzidas em um ambiente de produção. Portanto, quanto mais você puder controlar a qualidade e reduzir os defeitos no processo de construção, melhor. Projete pipelines de integração e implantação contínua (CI/CD) para testar problemas de segurança sempre que possível. Os pipelines de CI/CD oferecem a oportunidade de aumentar a segurança em cada estágio de criação e entrega. As ferramentas de segurança de CI/CD também devem estar sempre atualizadas para mitigar as ameaças em constante evolução.

Acompanhe as alterações na configuração de workload para ajudar na auditoria de conformidade, gerenciamento de alterações e investigações que possam ser aplicáveis. Você pode usar o AWS Config para registrar e avaliar seus recursos da AWS e de terceiros. Ele permite auditar e avaliar continuamente a conformidade geral com regras e pacotes de conformidade, que são coleções de regras com ações de correção.

O rastreamento de alterações deve incluir alterações planejadas, que fazem parte do processo de controle de alterações da sua organização [às vezes chamado de MACD, de Move, Add, Change, Delete (Mover, Adicionar, Alterar, Excluir)], alterações não planejadas e alterações inesperadas, como incidentes. Podem ocorrer alterações na infraestrutura, mas também podem estar relacionadas a outras categorias, como alterações em repositórios de código, imagens de máquina e alterações de inventário de aplicações, alterações de processos e políticas ou alterações de documentação.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Automatize o gerenciamento de configuração: aplique e valide configurações seguras automaticamente usando uma ferramenta ou um serviço de gerenciamento de configuração. 
  +  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
  +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
  +  [Configurar um pipeline CI/CD na AWS](https://aws.amazon.com/getting-started/projects/set-up-ci-cd-pipeline/)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Como usar políticas de controle de serviço para definir barreiras de proteção de permissão entre contas no AWS Organization](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/) 

 **Vídeos relacionados:** 
+  [Como gerenciar ambientes da AWS de várias contas usando o AWS Organizations](https://youtu.be/fxo67UeeN1A) 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP07 Identificar ameaças e priorizar mitigações com o uso de um modelo de ameaça
<a name="sec_securely_operate_threat_model"></a>

 Realize a modelagem de ameaças para identificar e manter um registro atualizado de possíveis ameaças e mitigações associadas para sua workload. Priorize suas ameaças e adapte as mitigações de controles de segurança para prevenir, detectar e responder. Revise e mantenha isso no contexto de sua workload e no cenário de segurança em evolução. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 **O que é modelagem de ameaças?** 

 “A modelagem de ameaças serve para identificar, comunicar e compreender as ameaças e as mitigações no contexto de proteção de algo de valor.” [The Open Web Application Security Project (OWASP) Application Threat Modeling](https://owasp.org/www-community/Threat_Modeling) 

 **Por que você deve ter um modelo de ameaças?** 

 Os sistemas são complexos e se tornam cada vez mais intrincados e qualificados com o passar do tempo, oferecendo maior valor empresarial e maior satisfação e engajamento do cliente. Isso significa que as decisões de design de TI precisam considerar um número cada vez maior de casos de uso. Essa complexidade e o número de permutações de caso de uso geralmente tornam as abordagens não estruturadas ineficazes para encontrar e mitigar ameaças. Em vez disso, você precisa de uma abordagem sistemática para enumerar as possíveis ameaças ao sistema, elaborar mitigações e priorizá-las a fim de garantir que os recursos limitados de sua organização tenham impacto máximo na melhoria do procedimento geral de segurança do sistema. 

 A modelagem de ameaças foi projetada para oferecer essa abordagem sistemática, com o objetivo de encontrar e resolver problemas na fase inicial do processo de design, quando as mitigações têm custo e esforço relativamente baixos em comparação com a fase posterior do ciclo de vida. Essa abordagem está alinhada ao princípio de [segurança *shift left*](https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview) (mover para a esquerda) do setor. Por fim, a modelagem de ameaças é integrada ao processo de gerenciamento de riscos de uma organização e ajuda a impulsionar as decisões sobre quais controles implementar usando uma abordagem orientada a ameaças. 

 **Quando a modelagem de ameaças deve ser realizada?** 

 Inicie a modelagem de ameaças o quanto antes no ciclo de vida de sua workload. Isso oferece a você maior flexibilidade sobre o que fazer com as ameaças identificadas. Muito semelhante aos bugs de software, quanto mais cedo você identificar ameaças, mais econômico será resolvê-las. Um modelo de ameaças é um documento ativo e deve continuar a evoluir à medida que suas workloads mudam. Revise seus modelos de ameaça no decorrer do tempo, inclusive quando há uma alteração importante ou uma alteração no cenário de ameaças ou ao adotar um novo recurso ou serviço. 

### Etapas da implementação
<a name="implementation-steps"></a>

 **Como podemos realizar a modelagem de ameaças?** 

 Há muitas formas diferentes de realizar a modelagem de ameaças. Muito semelhante às linguagens de programação, há vantagens e desvantagens em cada uma, e é necessário escolher a forma mais adequada para você. Uma abordagem é começar com o [Shostack’s 4 Question Frame for Threat Modeling](https://github.com/adamshostack/4QuestionFrame) (Estrutura de quatro perguntas do Shostack para modelagem de ameaças), que apresenta perguntas abertas a fim de oferecer estrutura ao seu exercício de modelagem de ameaças: 

1.  **Em que você está trabalhando?** 

    A finalidade dessa pergunta é ajudar você a entender e chegar a um acordo sobre o sistema que você está construindo e os detalhes sobre ele que são relevantes para a segurança. A criação de um modelo ou um diagrama é a forma mais comum de responder a essa pergunta, pois ele ajuda você a visualizar o que você está construindo; por exemplo, usando um [fluxograma de dados](https://en.wikipedia.org/wiki/Data-flow_diagram). Escrever as suposições e os detalhes importantes sobre seu sistema também ajuda a definir o que está no escopo. Isso permite que todos que estão contribuindo para o modelo de ameaças se concentrem na mesma coisa e evitem desvios demorados para tópicos fora do escopo (inclusive versões desatualizadas do sistema). Por exemplo, se você estiver criando uma aplicação web, provavelmente não vale a pena criar uma modelagem de ameaças da sequência de inicialização confiável do sistema operacional para clientes de navegador, pois não há nenhuma possibilidade de seu design ter influência nisso. 

1.  **O que pode dar errado?** 

    É nessa fase que você identifica ameaças ao seu sistema. Ameaças são ações ou eventos acidentais ou intencionais que têm impactos indesejados que podem afetar a segurança de seu sistema. Sem um claro entendimento do que pode dar errado, não há o que fazer sobre isso. 

    Não há uma lista canônica do que pode dar errado. A criação dessa lista exige etapas de brainstorming e colaboração entre todas as pessoas de sua equipe e as [pessoas relevantes envolvidas](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/#tips) no exercício de modelagem de ameaças. Você pode auxiliar suas etapas de brainstorming utilizando um modelo para identificar ameaças, como o [STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security)), que sugere categorias diferentes para avaliar: Spoofing (Falsificação), Tampering (Violação), Repudiation (Repúdio), Information disclosure (Divulgação de informações), Denial of service (Negação de serviço) e Elevation of privilege (Elevação de privilégio). Além disso, talvez você queira auxiliar as etapas de brainstorming revisando as listas existentes e a pesquisa para inspiração, como o [OWASP Top 10](https://owasp.org/www-project-top-ten/), o [HiTrust Threat Catalog](https://hitrustalliance.net/hitrust-threat-catalogue/) e o catálogo de ameaças de sua própria organização. 

1.  **O que estamos fazendo a respeito?** 

    Como no caso da primeira pergunta, não há uma lista canônica de todas as mitigações possíveis. A entradas nessa etapa são as ameaças identificadas, as pessoas e as áreas de melhoria da etapa anterior. 

    Segurança e conformidade são [responsabilidades compartilhadas entre você e a AWS](https://aws.amazon.com/compliance/shared-responsibility-model/). É importante entender que ao perguntar “O que vamos fazer a respeito?” você também pergunte “Quem é responsável por fazer algo a respeito?”. Entender o equilíbrio entre suas responsabilidades e as da AWS ajuda a definir o escopo de seu exercício de modelagem de ameaças para as mitigações que estão sob seu controle, que, geralmente, são uma combinação de opções de configuração de serviços da AWS e suas mitigações específicas ao sistema. 

    No que se refere à responsabilidade compartilhada da AWS, você descobrirá que os [serviços da AWS estão no escopo de muitos programas de conformidade](https://aws.amazon.com/compliance/services-in-scope/). Esses programas ajudam você a entender os controles sólidos implementados na AWS para manter a segurança e a conformidade da nuvem. Os relatórios de auditoria desses programas estão disponíveis para download para clientes da AWS do [AWS Artifact](https://aws.amazon.com/artifact/). 

    Seja quais forem os serviços da AWS que você esteja utilizando, sempre há um elemento de responsabilidade do cliente, e as mitigações alinhadas a essas responsabilidades devem ser incluídas em seu modelo de ameaças. Para mitigações de controle de segurança dos próprios serviços da AWS, convém considerar a implementação de controles de segurança em todos os domínios; por exemplo, domínios como gerenciamento de identidade e acesso (autenticação e autorização), proteção de dados (em repouso e em trânsito), segurança de infraestrutura, registro em log e monitoramento. A documentação de cada serviço da AWS tem um [capítulo dedicado à segurança](https://docs.aws.amazon.com/security/) que oferece orientações sobre os controles de segurança a serem considerados como mitigações. É importante considerar o código que você está escrevendo e suas dependências e pensar nos controles que você poderia implementar para resolver essas ameaças. Esses controles podem ser fatores como [validação de entrada](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), [processamento de sessões](https://owasp.org/www-project-mobile-top-10/2014-risks/m9-improper-session-handling) e [processamento de limites](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow). Com frequência, a maioria das vulnerabilidades é introduzida em código personalizado, então concentre-se nessa área. 

1.  **Fizemos um bom trabalho?** 

    O objetivo é a sua equipe e a organização aprimorarem a qualidade dos modelos de ameaças e a velocidade na qual você está realizando a modelagem de ameaças no decorrer do tempo. Essas melhorias vêm de uma combinação de prática, aprendizado, instrução e revisão. Para se aprofundar e trabalhar, é recomendável que você e sua equipe concluam o [curso de treinamento Threat modeling the right way for builders](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop) (Modelagem de ameças da maneira certa para desenvolvedores) ou o respectivo [workshop](https://catalog.workshops.aws/threatmodel/en-US). Além disso, se você estiver procurando orientações sobre como integrar a modelagem de ameaças ao ciclo de vida do desenvolvimento de aplicações da organização, consulte a publicação [Como abordar a modelagem de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) no Blog de segurança da AWS. 

 **Threat Composer** 

 Para ajudar e fornecer orientações ao criar a modelagem de ameaças, considere usar a ferramenta [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer), que visa reduzir o tempo de maturação na modelagem de ameaças. Essa ferramenta ajuda a fazer o seguinte: 
+  Escrever declarações úteis sobre ameaças alinhadas à [gramática de ameaças](https://catalog.workshops.aws/threatmodel/en-US/what-can-go-wrong/threat-grammar) que funcionem em um fluxo de trabalho natural e não linear. 
+  Gerar um modelo de ameaça legível por humanos. 
+  Gerar um modelo de ameaça legível por máquina para permitir tratar os modelos de ameaças como código. 
+  Ajudar a identificar rapidamente as áreas de melhoria da qualidade e de cobertura usando o painel do Insights. 

 Para obter mais referências, acesse o Threat Composer e alterne para o **Example Workspace** definido pelo sistema. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC01-BP03 Identificar e validar objetivos de controle](sec_securely_operate_control_objectives.md) 
+  [SEC01-BP04 Manter-se atualizado sobre as ameaças à segurança](sec_securely_operate_updated_threats.md) 
+  [SEC01-BP05 Manter-se atualizado com as recomendações de segurança](sec_securely_operate_updated_recommendations.md) 
+  [SEC01-BP08 Avaliar e implementar regularmente novos serviços e recursos de segurança](sec_securely_operate_implement_services_features.md) 

 **Documentos relacionados:** 
+  [Como abordar a modelagem de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (Blog de segurança da AWS) 
+ [NIST: Guia para modelagem de ameaças de sistemas centrados em dados](https://csrc.nist.gov/publications/detail/sp/800-154/draft)

 **Vídeos relacionados:** 
+ [AWS Summit ANZ 2021: Como abordar a modelagem de ameaças ](https://www.youtube.com/watch?v=GuhIefIGeuA)
+ [AWS Summit ANZ 2022: Escalar a segurança: otimizar para ter uma entrega rápida e segura ](https://www.youtube.com/watch?v=DjNPihdWHeA)

 **Treinamento relacionado:** 
+ [ Threat modeling the right way for builders (Modelagem de ameaças da maneira certa para desenvolvedores): treinamento autoguiado virtual do AWS Skill Builder ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)
+ [ Threat modeling the right way for builders – AWS Workshop ](https://catalog.workshops.aws/threatmodel) (Modelagem de ameaças da maneira certa para desenvolvedores)

 **Ferramentas relacionadas:** 
+  [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer) 

# SEC01-BP08 Avaliar e implementar regularmente novos serviços e recursos de segurança
<a name="sec_securely_operate_implement_services_features"></a>

 Avalie e implemente serviços e recursos de segurança da AWS e parceiros da AWS que permitem que você desenvolva a postura de segurança da sua workload. O blog de segurança da AWS destaca novos serviços e recursos, guias de implementação e orientações gerais de segurança da AWS. [Quais as novidades da AWS?](https://aws.amazon.com/new) é uma ótima forma de se manter atualizado com todos os novos recursos, serviços e anúncios da AWS. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Planeje revisões regulares: crie um calendário de atividades de análise que inclua os requisitos de conformidade, avaliar novos recursos e serviços de segurança da AWS e manter-se atualizado sobre as novidades do setor. 
+  Descubra os serviços e recursos da AWS: descubra os recursos de segurança disponíveis para os serviços que você está usando e analise os novos recursos à medida que são lançados. 
  + [ Blog de segurança da AWS](https://aws.amazon.com/blogs/security/) 
  + [ Boletins de segurança da AWS](https://aws.amazon.com/security/security-bulletins/)
  +  [Documentação do serviço da AWS](https://aws.amazon.com/documentation/)
+  Definir processo de integração de serviços da AWS: defina processos para integração de novos serviços da AWS. Inclua como você avalia os novos serviços da AWS em termos de funcionalidade e os requisitos de conformidade para sua workload. 
+  Teste novos serviços e recursos: teste novos serviços e recursos à medida que são lançados em um ambiente que não seja de produção que replica bem o ambiente de produção. 
+  Implemente outros mecanismos de defesa: implemente mecanismos automatizados para defender sua workload e explore as opções disponíveis. 
  +  [Como corrigir recursos não compatíveis da AWS pelo Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)

## Recursos
<a name="resources"></a>

 **Vídeos relacionados:** 
+  [Security Best Practices the Well-Architected Way ](https://youtu.be/u6BCVkXkPnM)

# Gerenciamento de identidade e acesso
<a name="a-identity-and-access-management"></a>

**Topics**
+ [SEGURANÇA 2. Como gerenciar a autenticação de pessoas e máquinas?](sec-02.md)
+ [SEGURANÇA 3. Como gerenciar permissões para pessoas e máquinas?](sec-03.md)

# SEGURANÇA 2. Como gerenciar a autenticação de pessoas e máquinas?
<a name="sec-02"></a>

 Há dois tipos de identidade que você precisa gerenciar para operar workloads seguras da AWS. Entender o tipo de identidade de que você precisa para gerenciar e conceder acesso ajuda a garantir que as identidades corretas tenham acesso aos recursos certos nas condições certas. 

Identidades humanas: seus administradores, desenvolvedores, operadores e usuários finais precisam de uma identidade para acessar ambientes e aplicações na AWS. Eles são membros de sua organização ou usuários externos com quem você colabora e que interagem com seus recursos da AWS por meio de um navegador da web, de uma aplicação cliente ou de ferramentas interativas de linha de comando. 

Identidades de máquina: aplicações de serviço, ferramentas operacionais e workloads precisam de uma identidade para fazer solicitações a serviços da AWS, como para ler dados. Essas identidades incluem máquinas em execução em seu ambiente da AWS, como instâncias do Amazon EC2 ou funções do AWS Lambda. Você também pode gerenciar identidades de máquina para partes externas que precisam de acesso. Além disso, você pode ter máquinas fora da AWS que precisam de acesso ao seu ambiente da AWS. 

**Topics**
+ [SEC02-BP01 Usar mecanismos de login fortes](sec_identities_enforce_mechanisms.md)
+ [SEC02-BP02 Usar credenciais temporárias](sec_identities_unique.md)
+ [SEC02-BP03 Armazenar e usar segredos com segurança](sec_identities_secrets.md)
+ [SEC02-BP04 Contar com um provedor de identidades centralizado](sec_identities_identity_provider.md)
+ [SEC02-BP05 Fazer a auditoria e a alternância periódica das credenciais](sec_identities_audit.md)
+ [SEC02-BP06 Utilizar grupos e atributos de usuários](sec_identities_groups_attributes.md)

# SEC02-BP01 Usar mecanismos de login fortes
<a name="sec_identities_enforce_mechanisms"></a>

Os logins (autenticação com credenciais de login) podem apresentar riscos quando não são usados mecanismos, como autenticação multifator (MFA), especialmente em situações em que as credenciais de login foram divulgadas acidentalmente ou podem ser deduzidas com facilidade. Utilize mecanismos de login fortes para reduzir essas riscos exigindo MFA e políticas de senhas fortes. 

 **Resultado desejado:** reduzir os riscos de acesso acidental a credenciais na AWS usando mecanismos de login fortes para usuários do [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), o [usuário raiz da Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html), o [Centro de Identidade do AWS IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) (sucessor do AWS Single Sign-On), e provedores de identidades de terceiros. Isso significa exigir MFA, impor políticas de senhas fortes e detectar comportamento de login anômalo. 

 **Antipadrões comuns:** 
+  Não impor uma política de senhas fortes para suas identidades incluindo senhas complexas e MFA. 
+  Compartilhar as mesmas credenciais entre usuários diferentes. 
+  Não utilizar controles de detecção para logins suspeitos. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Há muitas formas de identidades humanas fazerem login na AWS. É prática recomendada da AWS depender de um provedor de identidades centralizado utilizando federação (federação direta ou usando Centro de Identidade do AWS IAM) ao realizar a autenticação na AWS. Nesse caso, você deve estabelecer um processo de login seguro com seu provedor de identidades ou o Microsoft Active Directory. 

 Ao abrir pela primeira vez uma Conta da AWS, você começa com um usuário raiz da Conta da AWS. Você só deve usar o usuário raiz da conta para configurar o acesso para seus usuários (e para [tarefas que exijam o usuário raiz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). É importante ativar a MFA para o usuário raiz da conta logo após abrir sua Conta da AWS e para proteger o usuário raiz usando o [Guia de práticas recomendadas da AWS](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html). 

 Se você criar usuários no Centro de Identidade do AWS IAM, proteja o processo de login nesse serviço. Para identidades dos consumidores, é possível usar o [Amazon Cognito user pools](https://docs.aws.amazon.com/cognito/index.html) e proteger o processo de login nesse serviço ou usar os provedores de identidades compatíveis com o Amazon Cognito user pools. 

 Se estiver usando usuários do [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), você protegerá o processo de login com o IAM. 

 Seja qual for o método de login, é essencial impor uma política de login forte. 

 **Etapas da implementação** 

 Veja a seguir as recomendações gerais de login forte. As configurações reais devem ser definidas pela política de sua empresa ou usando um padrão como [NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html). 
+  Exija MFA. É [prática recomendada IAM exigir MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) para identidades humanas e workloads. A ativação da MFA oferece uma camada adicional de segurança que exige que os usuários forneçam credenciais de login e uma senha de uso único (OTP) ou uma string gerada e verificada criptograficamente por um dispositivo de hardware. 
+  Imponha um comprimento mínimo de senha, que é um fator essencial da força da senha. 
+  Imponha complexidade para tornar as senhas mais difíceis de deduzir. 
+  Permita que os usuários alterem suas próprias senhas. 
+  Crie identidades individuais em vez de credenciais compartilhadas. Com a criação de identidades individuais, é possível fornecer a cada usuário um conjunto exclusivo de credenciais de segurança. Os usuários individuais oferecem a capacidade de auditar a atividade de cada usuário. 

 Recomendações do IAM Identity Center: 
+  O IAM Identity Center oferece uma [política de senha](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) predefinida ao usar o diretório padrão que estabelece o comprimento da senha, a complexidade e requisitos de reutilização. 
+  [Ative a MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html) e defina a configuração de reconhecimento de contexto ou sempre ativo da MFA quando a origem da identidade for o diretório padrão, o AWS Managed Microsoft AD ou o AD Connector. 
+  Permita que os usuários [registrem seus próprios dispositivos de MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/how-to-allow-user-registration.html). 

 Recomendações de diretório do Amazon Cognito user pools: 
+  Defina as configurações de [força da senha](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html). 
+  [Exija MFA](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html) dos usuários. 
+  Use as [configurações de segurança avançadas](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html) do Amazon Cognito user pools para recursos como [autenticação adaptável](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html) que podem bloquear logins suspeitos. 

 Recomendações para usuários do IAM: 
+  Em teoria, você está utilizando IAM Identity Center ou federação direta. No entanto, talvez você precise de usuários do IAM. Nesse caso, [defina uma política de senha](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) para usuários do IAM. A política de senhas pode ser usada para definir requisitos como extensão mínima ou a obrigatoriedade de uso de caracteres não alfabéticos. 
+  Crie uma política do IAM com o objetivo de [impor login de MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1) para que os usuários possam gerenciar suas próprias senhas e dispositivos de MFA. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC02-BP03 Armazenar e usar segredos com segurança](sec_identities_secrets.md) 
+  [SEC02-BP04 Contar com um provedor de identidades centralizado](sec_identities_identity_provider.md) 
+  [SEC03-BP08 Compartilhar recursos com segurança em sua organização](sec_permissions_share_securely.md) 

 **Documentos relacionados:** 
+ [ Política de senha do Centro de Identidade do AWS IAM (sucessor do AWS Single Sign-On)](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)
+ [ Política de senha do usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [ Definir a senha do usuário raiz da Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [ Política de senha do Amazon Cognito ](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html)
+ [ Credenciais da AWS](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [ Práticas recomendadas de segurança no IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)

 **Vídeos relacionados:** 
+  [Gerenciar permissões de usuário em grande escala com o Centro de Identidade do AWS IAM](https://youtu.be/aEIqeFCcK7E) 
+  [Dominar a identidade em todos os aspectos](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP02 Usar credenciais temporárias
<a name="sec_identities_unique"></a>

 Ao realizar qualquer tipo de autenticação, é melhor utilizar credenciais temporárias em vez de credenciais de longo prazo a fim de reduzir ou eliminar riscos, como credenciais que são divulgadas acidentalmente, compartilhadas ou roubadas. 

**Resultado desejado:** para reduzir o risco de credenciais de longo prazo, use credenciais temporárias sempre que possível para identidades humanas e de máquina. Credenciais de longo prazo criam muitos riscos, por exemplo, é possível fazer upload delas em código para repositórios públicos do GitHub. Ao utilizar credenciais temporárias, você reduz significativamente as chances de comprometimento das credenciais. 

**Antipadrões comuns:**
+  Desenvolvedores que usam chaves de acesso de longo prazo de IAM users em vez de obter credenciais temporárias da CLI usando federação. 
+  Desenvolvedores que incorporam chaves de acesso de longo prazo no código e fazem upload desse código para repositórios públicos do Git. 
+  Desenvolvedores que incorporam chaves de acesso de longo prazo em aplicações móveis que, depois, são disponibilizadas em lojas de aplicações. 
+  Usuários que compartilham chaves de acesso de longo prazo com outros usuários ou funcionários que deixam a empresa e não devolvem as chaves de acesso de longo prazo. 
+  Utilizar chaves de acesso de longo prazo para identidades de máquina quando é possível usar credenciais temporárias. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Utilize credenciais de segurança temporárias em vez de credenciais de longo prazo para todas as solicitações da AWS CLI e API. As solicitações de API e CLI para serviços da AWS devem, em quase todos os casos, ser assinadas com [chaves de acesso da AWS](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html). Essas solicitações podem ser assinadas com credenciais temporárias ou de longo prazo. A única vez que você deve usar credenciais de longo prazo, também conhecidas como chaves de acesso de longo prazo, é se você estiver utilizando um [usuário do IAM](https://docs.aws.amazon.com//latest/UserGuide/id_users.html) ou o [usuário raiz da Conta da AWS](https://docs.aws.amazon.com//latest/UserGuide/id_root-user.html). Quando você usa federação na AWS ou assume um [perfil do IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles.html) por outros métodos, são geradas credenciais temporárias. Mesmo quando você acessa o Console de gerenciamento da AWS utilizando credenciais de login, credenciais temporárias são geradas para você fazer chamadas para serviços da AWS. Há poucas situações nas quais você precisa de credenciais de longo prazo, e é possível realizar quase todas as tarefas usando credenciais temporárias. 

 Evitar o uso de credenciais de longo prazo em favor de credenciais temporárias deve andar lado a lado com uma estratégia de reduzir o uso de usuários do IAM em favor da federação e de perfis do IAM. Embora usuários do IAM tenham sido usados para identidades humanas e de máquina no passado, agora recomendamos não utilizá-los para evitar os riscos de utilizar chaves de acesso de longo prazo. 

### Etapas da implementação
<a name="implementation-steps"></a>

 Para identidades humanas, como funcionários, administradores, desenvolvedores, operadores e clientes: 
+  Você deve [contar com um provedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) e [exigir que usuários humanos usem federação com um provedor de identidades para acessar a AWS utilizando credenciais temporárias](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#bp-users-federation-idp). A federação para seus usuários pode ser realizada com [federação direta para cada Conta da AWS](https://aws.amazon.com/identity/federation/) ou usando o [AWS IAM Identity Center (sucessor do Centro de Identidade do AWS IAM)](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) e o provedor de identidades de sua escolha. A federação oferece uma série de vantagens em comparação com a utilização de usuários do IAM além de eliminar credenciais de longo prazo. Seus usuários também podem solicitar credenciais temporárias da linha de comando para [federação direta](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/) ou utilizando o [IAM Identity Center](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html). Isso significa que há poucos casos de uso que exigem usuários do IAM ou credenciais de longo prazo para seus usuários.  
+  Ao conceder acesso a recursos em sua Conta da AWS a terceiros, como provedores de software como serviço (SaaS), você pode utilizar [perfis entre contas](https://docs.aws.amazon.com//latest/UserGuide/tutorial_cross-account-with-roles.html) e [políticas baseadas em recursos](https://docs.aws.amazon.com//latest/UserGuide/access_policies_identity-vs-resource.html). 
+  Se você precisar conceder a aplicações de consumidores ou clientes acesso aos seus recursos da AWS, você pode utilizar [grupos de identidade do Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) ou [Amazon Cognito user pools](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) para fornecer credenciais temporárias. As permissões para as credenciais são configuradas por meio de perfis do IAM. Você também pode definir um perfil do IAM separado com permissões limitadas para usuários convidados que não são autenticados. 

 Para identidades de máquina, talvez seja necessário utilizar credenciais de longo prazo. Nesses casos, você deve [exigir que as workloads utilizem credenciais temporárias com perfis da IAM para acessar a AWS](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#bp-workloads-use-roles). 
+  Para [Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/) (Amazon EC2), é possível usar [perfis do Amazon EC2](https://docs.aws.amazon.com//latest/UserGuide/id_roles_use_switch-role-ec2.html). 
+  O [AWS Lambda](https://aws.amazon.com/lambda/) permite configurar um [perfil de execução do Lambda para conceder permissões de serviço](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) a fim de executar ações da AWS usando credenciais temporárias. Há muitos outros modelos semelhantes para os serviços da AWS concederem credenciais temporárias utilizando perfis do IAM. 
+  Para serviços de IoT, é possível usar o [provedor de credenciais de AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) para solicitar credenciais temporárias. 
+  Para sistemas on-premises ou sistemas executados fora da AWS que precisem acessar os recursos da AWS, é possível utilizar o [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html). 

 Há cenários em que credenciais temporárias não são uma opção e talvez seja necessário usar credenciais de longo prazo. Nessas situações, [faça auditoria e alterne as credenciais periodicamente](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) e [alterne as chaves de acesso regularmente para casos de uso que exijam credenciais de longo prazo](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#rotate-credentials). Alguns exemplos que podem exigir credenciais de longo prazo incluem plug-ins do WordPress e clientes da AWS de terceiros. Em situações em que você precisa utilizar credenciais de longo prazo ou para credenciais que não sejam chaves de acesso da AWS, como logins de banco de dados, é possível usar um serviço projetado para lidar com o gerenciamento de segredos, como [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/). O Secrets Manager torna simples gerenciar, alternar e armazenar com segurança segredos criptografados utilizando [serviços compatíveis](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html). Para ter mais informações sobre a alternância de credenciais de longo prazo, consulte [Alternar chave de acesso](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [SEC02-BP03 Armazenar e usar segredos com segurança](sec_identities_secrets.md) 
+ [SEC02-BP04 Contar com um provedor de identidades centralizado](sec_identities_identity_provider.md) 
+ [SEC03-BP08 Compartilhar recursos com segurança em sua organização](sec_permissions_share_securely.md) 

 **Documentos relacionados:** 
+  [Credenciais de segurança temporárias](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html) 
+  [Credenciais da AWS](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html) 
+  [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html) 
+  [Perfis do IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles.html) 
+  [IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 
+  [Provedores de identidades e federação](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Alternar chaves de acesso](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) 
+  [Soluções de parceiros de segurança: acesso e controle de acesso](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [Usuário raiz da Conta da AWS](https://docs.aws.amazon.com//latest/UserGuide/id_root-user.html) 

 **Vídeos relacionados:** 
+  [Gerenciar permissões de acesso em grande escala com o AWS IAM Identity Center (sucessor do Centro de Identidade do AWS IAM](https://youtu.be/aEIqeFCcK7E) 
+  [Dominar a identidade em todos os aspectos](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP03 Armazenar e usar segredos com segurança
<a name="sec_identities_secrets"></a>

 Uma workload exige um recurso automatizado para comprovar a identidade dela em bancos de dados, recursos e serviços de terceiros. Isso é realizado com o uso de credenciais de acesso secretas, como chaves de acesso de API, senhas e tokens do OAuth. Utilizar um serviço com propósito específico para armazenar, gerenciar e alternar essas credenciais ajuda a reduzir a probabilidade de comprometimento dessas credenciais. 

**Resultado desejado:** implementar um mecanismo para gerenciar com segurança credenciais de aplicações que concretize os seguintes objetivos: 
+  Identificar quais segredos são necessários para a workload. 
+  Reduzir o número de credenciais de longo prazo necessárias substituindo-as por credenciais de curto prazo quando possível. 
+  Estabelecer um armazenamento seguro e uma alternância automatizada das credenciais de longo prazo restantes. 
+  Auditar o acesso aos segredos existentes na workload. 
+  Monitorar continuamente para confirmar que nenhum segredo seja incorporado a código-fonte durante o processo de desenvolvimento. 
+  Reduzir a probabilidade de divulgação acidental de credenciais. 

**Antipadrões comuns:**
+  Ausência de alternância de credenciais. 
+  Armazenar credenciais de longo prazo em código-fonte ou arquivos de configuração. 
+  Armazenar credenciais em repouso não criptografadas. 

 **Benefícios do estabelecimento desta prática recomendada:**
+  Os segredos são armazenados com criptografia em repouso e em trânsito. 
+  O acesso às credenciais é fechado por meio de uma API (pense nisso como uma *máquina automática de venda de credenciais*). 
+  O acesso a uma credencial (de leitura e gravação) é auditado e registrado. 
+  Separação de preocupações: a alternância de credenciais é realizada por um componente separado, que pode ser segregado do restante da arquitetura. 
+  Os segredos são automaticamente distribuídos sob demanda em componentes de software e a alternância ocorre em um local central. 
+  O acesso às credenciais pode ser controlado de forma detalhada. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Antes, as credenciais usadas para realizar a autenticação em bancos de dados, APIs de terceiros, tokens e outros segredos podiam ser incorporadas em código-fonte ou em arquivos do ambiente. A AWS oferece vários mecanismos para armazenar essas credenciais com segurança, alterná-las automaticamente e auditar o uso delas. 

 A melhor forma de abordar o gerenciamento de segredos é seguir as orientações de remover, substituir e alternar. A credencial mais segura é a que você não precisa armazenar, gerenciar nem processar. Pode haver credenciais que não sejam mais necessárias ao funcionamento da workload que podem ser removidas com segurança. 

 Para credenciais que ainda são necessárias ao funcionamento adequado da workload, pode haver uma oportunidade de substituir uma credencial de longo prazo por uma credencial temporária ou de curto prazo. Por exemplo, em vez de codificar uma chave de acesso secreta da AWS, pense em substituir essa credencial de longo prazo por uma temporária utilizando perfis do IAM. 

 Alguns segredos duradouros podem não ser removidos ou substituídos. Esses segredos podem ser armazenados em um serviço, como o [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), no qual eles podem ser armazenados centralmente, gerenciados e alternados regularmente. 

 Uma auditoria do código-fonte da workload e os arquivos de configuração podem revelar muitos tipos de credencial. A seguinte tabela resume as estratégias para lidar com tipos comuns de credenciais: 


|  Credential type  |  Description  |  Suggested strategy  | 
| --- | --- | --- | 
|  IAM access keys  |  AWS IAM access and secret keys used to assume IAM roles inside of a workload  |  Replace: Use [Perfis do IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios.html) assigned to the compute instances (such as [Amazon EC2](https://docs.aws.amazon.com//latest/UserGuide/id_roles_use_switch-role-ec2.html) or [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)) instead. For interoperability with third parties that require access to resources in your Conta da AWS, ask if they support [Acesso entre contas da AWS](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios_third-party.html). For mobile apps, consider using temporary credentials through [Grupos de identidades (identidades federadas) do Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html). For workloads running outside of AWS, consider [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) or [AWS Systems Manager Hybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html).  | 
|  SSH keys  |  Secure Shell private keys used to log into Linux EC2 instances, manually or as part of an automated process  |  Replace: Use [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) or [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) to provide programmatic and human access to EC2 instances using IAM roles.  | 
|  Application and database credentials  |  Passwords – plain text string  |  Rotate: Store credentials in [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and establish automated rotation if possible.  | 
|  Amazon RDS and Aurora Admin Database credentials  |  Passwords – plain text string  |  Replace: Use the [Integração do Secrets Manager ao Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html) or [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html). In addition, some RDS database types can use IAM roles instead of passwords for some use cases (for more detail, see [Autenticação de banco de dados do IAM](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.DBAuth.html)).  | 
|  OAuth tokens  |  Secret tokens – plain text string  |  Rotate: Store tokens in [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and configure automated rotation.  | 
|  API tokens and keys  |  Secret tokens – plain text string  |  Rotate: Store in [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and establish automated rotation if possible.  | 

 Um antipadrão comum é incorporar chaves de acesso do IAM ao código-fonte, a arquivos de configuração ou aplicativos móveis. Quando uma chave de acesso do IAM é necessária para comunicação com um serviço da AWS, utilize [credenciais de segurança temporárias (de curto prazo)](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html). Essas credenciais de curto prazo podem ser fornecidas por meio de [perfis do IAM para instâncias do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), [perfis de execução](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) para funções do Lambda, [perfis do Cognito IAM](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) para acesso de usuários móveis e [políticas do IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html) para dispositivos IoT. Ao fazer interface com terceiros, prefira [delegar o acesso a um perfil do IAM ](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios_third-party.html) com o acesso necessário aos recursos de sua conta em vez de configurar um usuário do IAM e enviar a terceiros a chave de acesso secreta desse usuário. 

 Há muitos casos em que a workload exige o armazenamento de segredos necessários para interoperar com outros serviços e recursos. O [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) foi concebido especificamente para gerenciar com segurança essas credenciais, bem como o armazenamento, o uso e a alternância de tokens de API, senhas e outras credenciais. 

 O AWS Secrets Manager oferece cinco recursos principais para proteger o armazenamento e o processamento de credenciais sigilosas: [criptografia em repouso](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html), [criptografia em trânsito](https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html), [auditoria abrangente](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html), [controle de acesso detalhado](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html) e [alternância de credenciais extensíveis](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html). Outros serviços de gerenciamento de segredos de parceiros da AWS ou soluções desenvolvidas localmente que oferecem recursos e garantias semelhantes também são aceitáveis. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Identifique caminhos de código que contenham credenciais codificadas usando ferramentas automatizadas, como o [Amazon CodeGuru](https://aws.amazon.com/codeguru/features/). 
   +  Utilize o Amazon CodeGuru para verificar seus repositórios de código. Depois de concluir a revisão, filtre `Type=Secrets` no CodeGuru para encontrar linhas de código problemáticas. 

1.  Identifique credenciais que possam ser removidas ou substituídas. 

   1.  Identifique credenciais não mais necessárias e marque-as para remoção. 

   1.  Para chaves secretas da AWS incorporadas ao código-fonte, substitua-as por perfis do IAM associados aos recursos necessários. Se parte de sua workload estiver fora do AWS, mas exigir credenciais do IAM para acessar recursos da AWS, considere o [IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) ou o [AWS Systems Manager Hybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html). 

1.  Para outros terceiros, segredos duradouros que exijam o uso da estratégia de alternância, integre o Secrets Manager ao seu código para recuperar segredos de terceiros no tempo de execução. 

   1.  O console do CodeGuru pode [criar um segredo automaticamente no Secrets Manager](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) utilizando as credenciais descobertas. 

   1.  Integre a recuperação de segredos do Secrets Manager ao código de sua aplicação. 
      +  Funções do Lambda Sem Servidor podem usar uma [extensão do Lambda](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html) independente de linguagem. 
      +  Para instâncias ou contêineres do EC2, a AWS oferece [código do lado do cliente de exemplo para recuperar segredos do Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) em várias linguagens de programação conhecidas. 

1.  Revise periodicamente sua base de código e verifique novamente para confirmar se não há novos segredos adicionados ao código. 
   +  Considere usar uma ferramenta como o [git-secrets](https://github.com/awslabs/git-secrets) para impedir a confirmação de novos segredos em seu repositório de código-fonte. 

1.  [Monitore a atividade do Secrets Manager ](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html) quanto a indicações de uso inesperado, acesso inadequado a segredos ou tentativas de excluir segredos. 

1.  Reduza a exposição humana às credenciais. Restrinja o acesso a credenciais de leitura, gravação e modificação a um perfil do IAM dedicado a esse fim, e apenas forneça acesso para assumir o perfil a um pequeno subconjunto de usuários operacionais. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [SEC02-BP02 Usar credenciais temporárias](sec_identities_unique.md)
+ [SEC02-BP05 Fazer a auditoria e a alternância periódica das credenciais](sec_identities_audit.md)

 **Documentos relacionados:** 
+  [Conceitos básicos do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [Provedores de identidades e federação](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Amazon CodeGuru apresenta o Secrets Detector](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) 
+  [Como o AWS Secrets Manager usa o AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html) 
+  [Criptografia e descriptografia de segredos no Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html) 
+  [Entradas do blog do Secrets Manager](https://aws.amazon.com/blogs/security/tag/aws-secrets-manager/) 
+  [Amazon RDS anuncia integração com o AWS Secrets Manager](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-rds-integration-aws-secrets-manager/) 

 **Vídeos relacionados:** 
+  [Práticas recomendadas para gerenciar, recuperar e alternar segredos em grande escala](https://youtu.be/qoxxRlwJKZ4) 
+  [Encontre segredos codificados com o Amazon CodeGuru Secrets Detector](https://www.youtube.com/watch?v=ryK3PN--oJs) 
+  [Proteger segredos para workloads híbridas usando o AWS Secrets Manager](https://www.youtube.com/watch?v=k1YWhogGVF8) 

 **Workshops relacionados:** 
+  [Armazenar, recuperar e gerenciar credenciais sigilosas no AWS Secrets Manager](https://catalog.us-east-1.prod.workshops.aws/workshops/497b4908-169f-4e6f-b80d-ef10be3038d3/en-US) 
+  [ Ativações híbridas do AWS Systems Manager](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html) 

# SEC02-BP04 Contar com um provedor de identidades centralizado
<a name="sec_identities_identity_provider"></a>

 Para identidades da força de trabalho (funcionários e prestadores de serviços), confie em um provedor de identidade que permita gerenciar identidades em um local centralizado. Isso facilita o gerenciamento do acesso em várias aplicações e sistemas, pois você está criando, atribuindo, gerenciando, revogando e auditando o acesso de um único local. 

 **Resultado desejado:** Você tem um provedor de identidade centralizado no qual gerencia centralmente os usuários da força de trabalho, as políticas de autenticação (como a exigência de autenticação multifator (MFA)) e a autorização para sistemas e aplicações (como atribuir acesso com base na associação ou nos atributos do grupo de um usuário). Os usuários da sua força de trabalho fazem login no provedor de identidade central e se federam (autenticação única) a aplicações internas e externas, eliminando a necessidade de os usuários se lembrarem de várias credenciais. Seu provedor de identidade é integrado aos seus sistemas de recursos humanos (RH) para que as mudanças de pessoal sejam automaticamente sincronizadas com seu provedor de identidade. Por exemplo, se alguém deixar sua organização, você poderá revogar automaticamente o acesso a aplicações e sistemas federados (inclusive a AWS). Você habilitou o registro em log detalhado de auditoria em seu provedor de identidade e está monitorando esses logs em busca de comportamentos incomuns do usuário. 

 **Antipadrões comuns:** 
+  Você não usa federação e autenticação única. Os usuários da sua força de trabalho criam contas de usuário e credenciais separadas em várias aplicações e sistemas. 
+  Você não automatizou o ciclo de vida das identidades dos usuários da força de trabalho, por exemplo, integrando seu provedor de identidade aos seus sistemas de RH. Quando um usuário deixa sua organização ou muda de função, você segue um processo manual para excluir ou atualizar seus registros em várias aplicações e sistemas. 

 **Benefícios de estabelecer esta prática recomendada:** Ao usar um provedor de identidade centralizado, você tem um único local para gerenciar as identidades e políticas dos usuários da força de trabalho, a capacidade de atribuir acesso às aplicações a usuários e grupos e a capacidade de monitorar a atividade de login do usuário. Ao se integrar aos seus sistemas de recursos humanos (RH), quando um usuário muda de função, essas alterações são sincronizadas com o provedor de identidade e atualizam automaticamente as aplicações e permissões atribuídas. Quando um usuário sai da sua organização, sua identidade é automaticamente desativada no provedor de identidade, revogando seu acesso a aplicações e sistemas federados. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida**: alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 **Orientação para usuários da força de trabalho que acessam a AWS** 

 Usuários da força de trabalho em sua organização, como funcionários e prestadores de serviços, podem precisar acessar a AWS usando o Console de gerenciamento da AWS ou a AWS Command Line Interface (AWS CLI) para realizar suas funções de trabalho. Você pode conceder acesso à AWS aos usuários da sua força de trabalho federando a partir de seu provedor de identidade centralizado para a AWS em dois níveis: federação direta para cada Conta da AWS ou federação para várias contas na [organização da AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html). 
+  Para federar os usuários da sua força de trabalho diretamente com cada Conta da AWS, você pode usar um provedor de identidade centralizado para federar o [AWS Identity and Access Management](https://aws.amazon.com/iam/) nessa conta. A flexibilidade do IAM permite que você habilite um [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) ou um [provedor de identidade Open ID Connect (OIDC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) para cada Conta da AWS e use atributos de usuário federados para controle de acesso. Os usuários da sua força de trabalho usarão o navegador da web para fazer login no provedor de identidade fornecendo suas respectivas credenciais (como senhas e códigos de token MFA). O provedor de identidade emite uma declaração SAML para o navegador, que é enviada ao URL de login do Console de gerenciamento da AWS para permitir que o usuário faça autenticação única no [Console de gerenciamento da AWS assumindo uma função do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html). Seus usuários também podem obter credenciais temporárias de API da AWS para uso na [AWS CLI](https://aws.amazon.com/cli/) ou [em AWS SDKs](https://aws.amazon.com/developer/tools/) pelo [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) assumindo [a função do IAM usando uma declaração SAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) do provedor de identidade. 
+  Para federar seus usuários da força de trabalho com várias contas em sua organização da AWS, você pode usar o [https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/) para gerenciar centralmente o acesso dos usuários de sua força de trabalho a Contas da AWS e aplicações. Você ativa o Centro de Identidade para sua organização e configura sua fonte de identidade. O IAM Identity Center fornece um diretório de origem de identidade padrão que você pode usar para gerenciar seus usuários e grupos. Como alternativa, você pode escolher uma fonte de identidade externa [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) usando SAML 2.0 e [provisionando automaticamente](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) usuários e grupos usando o SCIM ou [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html) com o uso do [Directory Service](https://aws.amazon.com/directoryservice/). Depois que uma fonte de identidade é configurada, você pode atribuir acesso a usuários e grupos a Contas da AWS definindo políticas de privilégios mínimos em seus [conjuntos de permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html). Os usuários da sua força de trabalho podem se autenticar por meio de seu provedor de identidade central para entrar no [portal de acesso da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html) e autenticação única em Contas da AWS e aplicações em nuvem atribuídas a eles. Seus usuários podem configurar a [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) para se autenticar com o Centro de Identidade e obter credenciais para executar comandos da AWS CLI. O Centro de Identidade também permite acesso com autenticação única a aplicações da AWS, como o [Amazon SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) e [portais do AWS IoT Sitewise Monitor](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html). 

 Depois de seguir as orientações anteriores, os usuários da sua força de trabalho não precisarão mais usar IAM users e grupos para operações normais ao gerenciar workloads na AWS. Em vez disso, seus usuários e grupos são gerenciados fora da AWS e os usuários podem acessar os recursos da AWS como uma *identidade federada*. As identidades federadas usam os grupos definidos pelo seu provedor de identidade centralizado. Você deve identificar e remover grupos do IAM, IAM users e credenciais de usuário de longa duração (senhas e chaves de acesso) que não são mais necessárias nas suas Contas da AWS. Você pode [encontrar credenciais não utilizadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) com o uso do [relatórios de credenciais do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html), [excluindo IAM users correspondentes](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html) e [excluindo grupos do IAM.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html) Você pode aplicar uma [política de controle de serviços (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) na sua organização, o que ajudará a impedir a criação de novos grupos e IAM users, forçando que esse acesso ocorra por meio de identidades federadas da AWS. 

 **Orientação para usuários de suas aplicações** 

 Você pode gerenciar as identidades dos usuários de suas aplicações, como um aplicativo móvel, usando o [https://aws.amazon.com/cognito/](https://aws.amazon.com/cognito/) como seu provedor de identidade centralizado. O Amazon Cognito permite autenticação, autorização e gerenciamento de usuários de seus aplicativos móveis e da web. O Amazon Cognito fornece um repositório de identidades que pode ser expandido para milhões de usuários, oferece suporte à federação de identidades sociais e corporativas e oferece recursos avançados de segurança para ajudar a proteger seus usuários e sua empresa. Você pode integrar seu aplicativo web ou móvel personalizado ao Amazon Cognito para adicionar autenticação de usuário e controle de acesso aos seus aplicativos em minutos. Desenvolvido com base em padrões de identidade abertos, como SAML e Open ID Connect (OIDC), o Amazon Cognito oferece suporte a vários regulamentos de conformidade e se integra aos recursos de desenvolvimento de front-end e back-end. 

### Etapas da implementação
<a name="implementation-steps"></a>

 **Etapas para usuários da força de trabalho acessarem a AWS** 
+  Federe os usuários da sua força de trabalho à AWS usando um provedor de identidade centralizado de acordo com uma das seguintes abordagens: 
  +  Use o IAM Identity Center para habilitar a autenticação única para várias Contas da AWS em sua organização da AWS, federando com seu provedor de identidade. 
  +  Use o IAM para conectar seu provedor de identidade diretamente a cada Conta da AWS, permitindo acesso federado refinado. 
+  Identifique e remova IAM users e grupos que são substituídos por identidades federadas. 

 **Etapas para usuários de suas aplicações** 
+  Use o Amazon Cognito como um provedor de identidade centralizado para suas aplicações. 
+  Integre suas aplicações personalizadas com o Amazon Cognito usando o OpenID Connect e o OAuth. Você pode desenvolver suas aplicações personalizadas usando as bibliotecas do Amplify que fornecem interfaces simples para integração com uma variedade de serviços da AWS, como o Amazon Cognito para autenticação. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [SEC02-BP06 Utilizar grupos e atributos de usuários](sec_identities_groups_attributes.md) 
+  [SEC03-BP02 Conceder acesso com privilégio mínimo](sec_permissions_least_privileges.md) 
+  [SEC03-BP06 Gerenciar o acesso com base no ciclo de vida](sec_permissions_lifecycle.md) 

 **Documentos relacionados:** 
+  [Federação de identidades na AWS](https://aws.amazon.com/identity/federation/) 
+  [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [Práticas recomendadas do AWS Identity and Access Management](https://aws.amazon.com/iam/resources/best-practices/) 
+  [Introdução à administração delegada do IAM Identity Center](https://aws.amazon.com/blogs/security/getting-started-with-aws-sso-delegated-administration/) 
+  [Como usar políticas gerenciadas pelo cliente no IAM Identity Center para casos de uso avançados](https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanced-use-cases/) 
+  [AWS CLI v2: provedor de credenciais do IAM Identity Center](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html) 

 **Vídeos relacionados:** 
+  [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive (AWS re:Inforce 2022: aprofundamento no AWS Identity and Access Management (IAM))](https://youtu.be/YMj33ToS8cI) 
+  [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center (AWS re:Invent 2022: simplifique o acesso existente de sua força de trabalho com o IAM Identity Center)](https://youtu.be/TvQN4OdR_0Y) 
+  [AWS re:Invent 2018: Mastering Identity at Every Layer of the Cake (AWS re:Invent 2018: dominar a identidade em todos os aspectos)](https://youtu.be/vbjFjMNVEpc) 

 **Exemplos relacionados:** 
+  [Workshop: Using Centro de Identidade do AWS IAM to achieve strong identity management (Uso do Centro de Identidade do AWS IAM para conseguir um forte gerenciamento de identidade)](https://catalog.us-east-1.prod.workshops.aws/workshops/590f8439-42c7-46a1-8e70-28ee41498b3a/en-US) 
+  [Workshop: Serverless identity (Identidade sem servidor)](https://identity-round-robin.awssecworkshops.com/serverless/) 

 **Ferramentas relacionadas:** 
+  [Parceiros de competência em segurança da AWS: gerenciamento de identidade e acesso](https://aws.amazon.com/security/partner-solutions/) 
+  [saml2aws](https://github.com/Versent/saml2aws) 

# SEC02-BP05 Fazer a auditoria e a alternância periódica das credenciais
<a name="sec_identities_audit"></a>

Audite e alterne as credenciais periodicamente para limitar o período durante o qual as credenciais podem ser usadas para acessar seus recursos. Credenciais de longo prazo criam muitos riscos, e estes podem ser reduzidos alternando credenciais de longo prazo regularmente.

 **Resultado desejado:** implementar a alternância de credenciais para ajudar a reduzir os riscos associados ao uso de credenciais de longo prazo. Auditar e corrigir regularmente a não conformidade com políticas de alternância de credenciais. 

 **Antipadrões comuns:** 
+  Não auditar o uso de credenciais. 
+  Utilizar credenciais de longo prazo desnecessariamente. 
+  Utilizar credenciais de longo prazo e não alterná-las regularmente. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Quando você não puder contar com credenciais temporárias e exigir credenciais de longo prazo, faça uma auditoria das credenciais para garantir que os controles definidos, por exemplo, autenticação multifator (MFA), sejam aplicados, alternados regularmente e que tenham o nível de acesso apropriado. 

 A validação periódica, preferencialmente por meio de uma ferramenta automatizada, é necessária para verificar se os controles corretos são aplicados. Para identidades humanas, você deve exigir que os usuários alterem suas senhas periodicamente e substituam chaves de acesso por credenciais temporárias. Ao migrar de usuários do AWS Identity and Access Management (IAM) para identidades centralizadas, é possível [gerar um relatório de credenciais](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) para fazer auditoria de seus usuários. 

 Também recomendamos implementar e monitorar a MFA no provedor de identidades. É possível configurar o [Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) ou usar [Padrões de segurança AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-iam-3) para monitorar se os usuários têm a MFA ativada. Considere utilizar o IAM Roles Anywhere para fornecer credenciais temporárias para identidades de máquina. Em situações em que o uso de perfis do IAM e credenciais temporárias não é possível, é necessário realizar auditoria frequente e alternar as chaves de acesso. 

 **Etapas da implementação** 
+  **Fazer auditoria nas credenciais regularmente:** a auditoria das identidades configuradas em seu provedor de identidades e no IAM ajuda a garantir que somente identidades autorizadas tenham acesso à sua workload. Essas identidades podem incluir, entre outros, usuários do IAM, do Centro de Identidade do AWS IAM, do Active Directory ou usuários em um provedor de identidades upstream diferente. Por exemplo, remova as pessoas que saem da organização e as funções entre contas que não são mais necessárias. Estabeleça um processo para auditar periodicamente as permissões para os serviços acessados por uma entidade do IAM. Isso ajuda a identificar as políticas que você precisa modificar a fim de remover todas as permissões não utilizadas. Use relatórios de credenciais e o [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) para auditar credenciais e permissões do IAM. É possível utilizar o [Amazon CloudWatch para configurar alarmes para chamadas de API específicas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) chamadas em seu ambiente da AWS. [O Amazon GuardDuty também pode alertar você sobre atividade inesperada](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html), que pode indicar acesso excessivamente permissivo ou acesso acidental às credenciais do IAM. 
+  **Alternar credenciais regularmente:** quando você não pode utilizar credenciais temporárias, alterne as chaves de acesso do IAM de longo prazo regularmente (no máximo, a cada 90 dias). Se uma chave de acesso for divulgada acidentalmente sem seu conhecimento, isso limitará o período de uso das credenciais para acessar seus recursos. Para ter informações sobre a alternância de chaves de acesso para usuários do IAM, consulte [Alternar chaves de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey). 
+  **Revisar as permissões do IAM**: para melhorar a segurança de sua Conta da AWS, revise e monitore regularmente cada uma das políticas do IAM. Verifique se as políticas seguem o princípio de privilégio mínimo. 
+  **Considerar automatizar a criação e as atualizações dos recursos do IAM:**o IAM Identity Center automatiza muitas tarefas do IAM, como o gerenciamento de perfis e políticas. Como alternativa, o AWS CloudFormation pode ser usado para automatizar a implantação de recursos do IAM, como perfis e políticas, para reduzir a chance de erros humanos, pois os modelos podem ser verificados e ter controle de versão. 
+  **Utilizar o IAM Roles Anywhere para substituir os usuários do IAM para identidades de máquina:** o IAM Roles Anywhere possibilita usar perfis em áreas onde não seria possível tradicionalmente, como em servidores on-premises. O IAM Roles Anywhere utiliza um certificado X.509 confiável para realizar a autenticação na AWS e receber credenciais temporárias. O uso do IAM Roles Anywhere evita a necessidade de alternar essas credenciais, pois credenciais de longo prazo não são mais armazenadas em seu ambiente on-premises. Você precisará monitorar e alternar o certificado X.509 ao aproximar-se da validade. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC02-BP02 Usar credenciais temporárias](sec_identities_unique.md) 
+  [SEC02-BP03 Armazenar e usar segredos com segurança](sec_identities_secrets.md) 

 **Documentos relacionados:** 
+  [Conceitos básicos do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [Práticas recomendadas do IAM](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html) 
+  [Provedores de identidades e federação](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Soluções de parceiros de segurança: acesso e controle de acesso](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [Credenciais de segurança temporárias](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html) 
+ [ Obter relatórios de credenciais da sua Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)

 **Vídeos relacionados:** 
+  [Práticas recomendadas para gerenciar, recuperar e alternar segredos em grande escala](https://youtu.be/qoxxRlwJKZ4) 
+  [Gerenciar permissões de usuário em grande escala com o Centro de Identidade do AWS IAM](https://youtu.be/aEIqeFCcK7E) 
+  [Dominar a identidade em todos os aspectos](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

 **Exemplos relacionados:** 
+ [ Well-Architected Lab: Limpeza automatizada de usuários do IAM ](https://wellarchitectedlabs.com/security/200_labs/200_automated_iam_user_cleanup/)
+ [ Well-Architected Lab: Implantação automatizada de grupos e perfis do IAM ](https://wellarchitectedlabs.com/security/200_labs/200_automated_deployment_of_iam_groups_and_roles/)

# SEC02-BP06 Utilizar grupos e atributos de usuários
<a name="sec_identities_groups_attributes"></a>

 À medida que o número de usuários gerenciados cresce, você precisará determinar maneiras de organizá-los para que você possa gerenciá-los em grande escala. Coloque usuários com requisitos de segurança comuns em grupos definidos pelo provedor de identidade e implemente mecanismos para garantir que os atributos de usuário que podem ser usados para controle de acesso (por exemplo, departamento ou localização) estejam corretos e atualizados. Use esses grupos e atributos para controlar o acesso em vez de usuários individuais. Isso permite que você gerencie o acesso centralmente, alterando a associação ao grupo ou os atributos de um usuário uma vez com um [conjunto de permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsets.html), em vez de atualizar várias políticas individuais quando as necessidades de acesso de um usuário mudarem. Você pode usar o Centro de Identidade do AWS IAM (IAM Identity Center) para gerenciar grupos e atributos de usuários. O IAM Identity Center oferece suporte aos atributos mais usados, quer eles sejam inseridos manualmente durante a criação do usuário ou provisionados automaticamente usando um mecanismo de sincronização, como definido na especificação System for Cross-Domain Identity Management (SCIM). 

Coloque usuários com requisitos de segurança comuns em grupos definidos pelo provedor de identidade e implemente mecanismos para garantir que os atributos de usuário que podem ser usados para controle de acesso (por exemplo, departamento ou localização) estejam corretos e atualizados. Use esses grupos e atributos, em vez de usuários individuais, para controlar o acesso. Com isso, você pode gerenciar o acesso centralmente. Basta alterar uma vez a associação ou os atributos do grupo de um usuário. Ou seja, não será preciso atualizar muitas políticas individuais quando as necessidades de acesso de um usuário mudarem.

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Se estiver usando o Centro de Identidade do AWS IAM (IAM Identity Center), configure grupos: o IAM Identity Center permite configurar grupos de usuários e atribuir aos grupos o nível desejado de permissão. 
  +  [AWS Single Sign-On: gerenciar identidades](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) 
+  Saiba mais sobre o controle de acesso por atributo (ABAC): o ABAC é uma estratégia de autorização que define permissões com base em atributos. 
  +  [O que é ABAC para a AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
  +  [Laboratório: Controle de acesso baseado em tags do IAM para o EC2](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Conceitos básicos do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [Práticas recomendadas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [Provedores de identidade e federação](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  [O usuário raiz da conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 

 **Vídeos relacionados:** 
+  [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale (Práticas recomendadas para gerenciar, recuperar e alternar segredos em grande escala)](https://youtu.be/qoxxRlwJKZ4) 
+  [Managing user permissions at scale with Centro de Identidade do AWS IAM (Gerenciar permissões de usuário em grande escala com o AWS SSO)](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

 **Exemplos relacionados:** 
+  [Laboratório: Controle de acesso baseado em tags do IAM para o EC2](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) 

# SEGURANÇA 3. Como gerenciar permissões para pessoas e máquinas?
<a name="sec-03"></a>

 Gerencie permissões para controlar o acesso a identidades de pessoas e máquinas que precisam de acesso à AWS e à sua workload. As permissões controlam quem pode acessar o quê e em quais condições. 

**Topics**
+ [SEC03-BP01 Definir requisitos de acesso](sec_permissions_define.md)
+ [SEC03-BP02 Conceder acesso com privilégio mínimo](sec_permissions_least_privileges.md)
+ [SEC03-BP03 Estabelecer processo de acesso de emergência](sec_permissions_emergency_process.md)
+ [SEC03-BP04 Reduzir as permissões continuamente](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 Definir barreiras de proteção de permissões para sua organização](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 Gerenciar o acesso com base no ciclo de vida](sec_permissions_lifecycle.md)
+ [SEC03-BP07 Analisar o acesso público e entre contas](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 Compartilhar recursos com segurança em sua organização](sec_permissions_share_securely.md)
+ [SEC03-BP09 Compartilhar recursos com segurança com terceiros](sec_permissions_share_securely_third_party.md)

# SEC03-BP01 Definir requisitos de acesso
<a name="sec_permissions_define"></a>

Cada componente ou recurso de sua workload precisa ser acessado por administradores, usuários finais ou outros componentes. É necessário ter uma definição clara de quem ou do que deve ter acesso a cada componente, escolher o tipo de identidade apropriado e o método de autenticação e autorização.

 **Antipadrões comuns:** 
+ Codificação rígida ou armazenamento de segredos em sua aplicação. 
+ Conceder permissões personalizadas a cada usuário. 
+ Uso de credenciais de longa duração. 

 **Nível de risco exposto se essa prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Cada componente ou recurso de sua workload precisa ser acessado por administradores, usuários finais ou outros componentes. É necessário ter uma definição clara de quem ou do que deve ter acesso a cada componente, escolher o tipo de identidade apropriado e o método de autenticação e autorização.

O acesso regular a Contas da AWS na organização deve ser fornecido usando [acesso federado](https://aws.amazon.com/identity/federation/) ou um provedor de identidade centralizado. Você também deve centralizar o gerenciamento de identidades e garantir que haja uma prática estabelecida para integrar o acesso à AWS ao ciclo de vida de acesso dos funcionários. Por exemplo, quando um funcionário muda para um cargo com um nível de acesso diferente, sua associação ao grupo também deve mudar para refletir os novos requisitos de acesso.

 Ao definir os requisitos de acesso para identidades não humanas, determine quais aplicações e componentes precisam de acesso e como as permissões são concedidas. O uso de perfis do IAM criados com o modelo de acesso de privilégio mínimo é uma abordagem recomendada. [As políticas gerenciadas pela AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) fornecem políticas predefinidas do IAM que abordam a maioria dos casos de uso comuns.

Os serviços da AWS, como o [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) e [o AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html), podem ajudar a desacoplar segredos da aplicação ou workload com segurança em casos em que não é possível usar perfis do IAM. No Secrets Manager, você pode estabelecer uma alternância automática de suas credenciais. É possível usar o Systems Manager para referenciar parâmetros em seus scripts, comandos, documentos do SSM, configurações e fluxos de trabalho de automação, usando o nome exclusivo que você especificou ao criar o parâmetro.

Você pode usar o AWS Identity and Access Management Roles Anywhere para obter [credenciais de segurança temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) para workloads executadas fora da AWS. As workloads podem usar as mesmas [políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) e [perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que você usa com as aplicações da AWS para acessar os recursos da AWS. 

 Quando possível, prefira credenciais temporárias de curta duração em vez de credenciais estáticas de longa duração. Para cenários em que você precisa de usuários da IAM com acesso programático e credenciais de longa duração, use [as últimas informações usadas da chave de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) para alternar e remover chaves de acesso. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [Centro de Identidade do AWS IAM](https://aws.amazon.com/iam/identity-center/) 
+  [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 
+  [AWS Managed policies for IAM Identity Center (Políticas gerenciadas pela AWS para o IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) 
+  [AWS IAM policy conditions (Condições de políticas do AWS IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) 
+  [IAM use cases (Casos de uso do IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html) 
+  [Remova credenciais desnecessárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+  [Trabalhando com políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 
+  [How to control access to AWS resources based on Conta da AWS, OU, or organization (Como controlar o acesso aos recursos da AWS baseados em Conta da AWS, UO ou organização)](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/) 
+  [Identify, arrange, and manage secrets easily using enhanced search in AWS Secrets Manager (Identificar, organizar e gerenciar segredos facilmente usando a pesquisa avançada no AWS Secrets Manager)](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) 

 **Vídeos relacionados:** 
+  [Become an IAM Policy Master in 60 Minutes or Less (Torne-se um mestre em políticas do IAM em 60 minutos ou menos)](https://youtu.be/YQsK4MtsELU) 
+  [Separation of Duties, Least Privilege, Delegation, and CI/CD (Separação de tarefas, privilégio mínimo, delegação e CI/CD)](https://youtu.be/3H0i7VyTu70) 
+  [Streamlining identity and access management for innovation (Simplificação do gerenciamento de identidade e acesso para inovação)](https://www.youtube.com/watch?v=3qK0b1UkaE8) 

# SEC03-BP02 Conceder acesso com privilégio mínimo
<a name="sec_permissions_least_privileges"></a>

 É prática recomendada conceder somente o acesso de que as identidades precisam para realizar ações em recursos específicos e sob condições específicas. Use grupos e atributos de identidade para definir permissões dinamicamente em escala, em vez de definir permissões para usuários individuais. Por exemplo, você pode permitir o acesso de um grupo de desenvolvedores para gerenciar apenas recursos de seu próprio projeto. Dessa forma, se um desenvolvedor sair do projeto, o acesso dele é automaticamente revogado sem alterar as políticas de acesso adjacentes. 

**Resultado desejado:** os usuário somente têm permissões necessárias para fazerem seus respectivos trabalhos. Os usuários devem ter acesso apenas a ambientes de produção para realizar uma tarefa específica dentro de um período limitado e o acesso deve ser revogado quando a tarefa for concluída. As permissões devem ser revogadas quando não forem mais necessárias, incluindo quando um usuário for para um projeto diferente ou mudar de cargo. Privilégios de administrador devem ser concedidos apenas a um grupo pequeno de administradores confiáveis. As permissões devem ser revistas regularmente para evitar desvios de permissão. Contas de máquina ou sistema devem ter apenas o mínimo de permissões necessárias para concluir as tarefas. 

**Antipadrões comuns:**
+  Usar como padrão a concessão de permissões de administrador aos usuários. 
+  Usar o usuário raiz para atividades diárias. 
+  Criar políticas permissivas demais, mas sem privilégios completos de administrador. 
+  Não revisar as permissões para entender se elas permitem o acesso de privilégio mínimo. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 O princípio de estados [privilégio mínimo](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#grant-least-privilege) para as identidades deve ser apenas permitido para realizar o mínimo de ações necessárias para cumprir uma tarefa específica. Isso equilibra a usabilidade, eficiência e segurança. Operar sobre esse princípio ajuda a limitar acesso não intencional e a rastrear quem tem acesso a quais recursos. Usuários e perfis do IAM não têm permissões por padrão. O usuário raiz tem acesso total e deve ser controlado e monitorado rigidamente, além de usado apenas para [tarefas que necessitam acesso raiz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). 

 Políticas do IAM são usadas para conceder explicitamente permissões aos perfis do IAM ou recursos específicos. Por exemplo, políticas com base em identidade podem ser anexadas a grupos do IAM, enquanto buckets do S3 podem ser controlados por políticas baseadas em recursos. 

 Ao criar e associar uma política do IAM, você pode especificar as ações de serviço, os recursos e as condições que devem ser verdadeiras para que a AWS permita ou negue o acesso. A AWS oferece suporte a uma variedade de condições para ajudar você a reduzir o acesso. Por exemplo, ao usar `PrincipalOrgID` como [chave de condição](https://docs.aws.amazon.com//latest/UserGuide/reference_policies_condition-keys.html), você pode negar ações se o solicitante não for parte da sua organização da AWS. 

 Você também pode controlar as solicitações feitas pelos serviços da AWS em seu nome, como a criação, pelo AWS CloudFormation, de uma função do AWS Lambda, usando a chave de condição `CalledVia`. Tipos diferentes de política devem estar em camadas para estabelecer a defesa em profundidade e limitar as permissões gerais de seus usuários. Você pode restringir as permissões que podem ser concedidas e sob quais condições. Por exemplo, você pode permitir que suas equipes de aplicação criem suas próprias políticas do IAM para os sistemas que criam, mas deve também aplicar uma [Fronteira de permissão](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) para limitar o máximo de permissões que o sistema pode receber. 

 **Etapas da implementação** 
+  **Implementar políticas de privilégio mínimo**: atribua políticas de acesso com privilégio mínimo a grupos e perfis do IAM para refletir a função ou o perfil do usuário que você definiu. 
  +  **Basear as políticas no uso da API**: uma maneira de determinar as permissões necessárias é analisar os logs do AWS CloudTrail. Essa análise permite que você crie permissões personalizadas para as ações do usuário dentro da AWS. O [IAM Access Analyzer pode gerar automaticamente uma IAM política com base](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) [na atividade](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/). Você pode usar o IAM Access Advisor no nível da organização ou da conta para [rastrear](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html) [as últimas informações acessadas para determinada política](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html). 
+  **Considerar o uso de [políticas gerenciadas da AWS para cargos](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html).** Pode ser difícil saber por onde começar ao criar políticas de permissões mais estritas. A AWS gerencia políticas para cargos comuns, como faturamento, administradores de banco de dados e cientistas de dados. Essas políticas podem ajudar a diminuir o acesso dos usuários ao determinar como implementar as políticas de privilégio mínimo. 
+  **Remover permissões desnecessárias:** remova permissões que não são necessárias e ajuste políticas muito permissivas. A [geração de política pelo IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/access-analyzer-policy-generation.html) pode ajudar a ajustar as políticas de permissão. 
+  **Garantir que os usuários tenham acesso limitado a ambientes de produção:** os usuários devem ter acesso a ambientes de produção apenas com um caso de uso válido. Depois de o usuário realizar as tarefas específicas para as quais foi necessário o acesso à produção, o acesso deve ser revogado. Limitar o acesso a ambientes de produção evita eventos não intencionais e que causam impacto à produção, além de diminuir o escopo do impacto do acesso não intencional. 
+ **Considerar os limites de permissões:** um limite de permissões é um recurso para usar uma política gerenciada que define o número máximo de permissões que uma política baseada em identidade pode conceder a uma entidade do IAM. O limite de permissões de uma entidade permite que ela execute apenas as ações aceitas por suas políticas baseadas em identidade e seus limites de permissões.  
+  **Considerar [tags de recursos](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) para permissões:** um modelo de controle de acesso baseado em atributo que usa tags de recursos permite conceder acesso com base no propósito do recurso, proprietário, ambiente ou outros critérios. Por exemplo, você pode usar tags de recurso para diferenciar entre ambientes de desenvolvimento e produção. Ao usar essas tags, é possível restringir os desenvolvedores ao ambiente de desenvolvimento. Ao combinar as tags e as políticas de permissões, você consegue alcançar um acesso restrito ao recurso sem precisar definir políticas complicadas e personalizadas para cada cargo. 
+  **Use [políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) para AWS Organizations.** As políticas de controle de serviço controlam centralmente o máximo de permissões disponíveis para contas de membros em sua organização. É importante notar que as políticas de controle de serviço permitem que você restrinja as permissões do usuário raiz nas contas de membros. Considere também o uso do AWS Control Tower, que fornece controles gerenciados prescritivos que enriquecem o AWS Organizations. Também é possível definir os seus próprios controles no Control Tower. 
+  **Estabelecer uma política de ciclo de vida para sua organização:** as políticas de ciclo de vida do usuário definem tarefas a serem realizadas quando os usuários entram na AWS, mudam de cargo ou escopo de trabalho ou não precisam mais de acesso à AWS. As análises de permissão devem ser feitas durante todas as etapas do ciclo de vida do usuário para verificar se as permissões estão adequadamente restritas e para evitar desvios nas permissões. 
+  **Estabelecer uma programação regular para rever as permissões e remover as permissões desnecessárias:** frequentemente, você deve verificar o acesso do usuário para garantir que ele não tenha acesso muito permissivo. O [AWS Config](https://aws.amazon.com/config/) e o IAM Access Analyzer podem ajudar ao auditar as permissões do usuário. 
+ **Estabelecer uma matriz de cargos:** uma matriz de cargos exibe os diversos cargos e níveis de acesso necessários dentro de sua área da AWS. Com uma matriz de cargos, você pode definir e separar as permissões com base nas responsabilidades do usuário dentro da sua organização. Use grupos em vez de aplicar permissões diretamente a usuários ou cargos individuais.**  **

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Conceder privilégio mínimo](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html?ref=wellarchitected#grant-least-privilege) 
+  [Permissions boundaries for IAM entities](https://docs.aws.amazon.com//latest/UserGuide/access_policies_boundaries.html) (Limites de permissões para entidades do IAM) 
+  [Techniques for writing least privilege IAM policies](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/) (Técnicas para escrever políticas do IAM de privilégio mínimo) 
+  [IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/) [policies based on access activity](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/) (IAM Access Analyzer facilita a implementação de permissões de privilégio mínimo gerando políticas do IAM baseadas na atividade de acesso) 
+  [Delegate permission management to developers by using IAM permissions boundaries](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) (Delegar gerenciamento de permissões para desenvolvedores usando os limites de permissões do IAM) 
+  [Refining Permissions using last accessed information (Refinar permissões usando as últimas informações acessadas)](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html) 
+  [IAM policy types and when to use them](https://docs.aws.amazon.com//latest/UserGuide/access_policies.html) (Tipos de política do IAM e quando usá-las) 
+  [Testing IAM policies with the IAM policy simulator](https://docs.aws.amazon.com//latest/UserGuide/access_policies_testing-policies.html) (Testar políticas do IAM com o simulador de política do IAM) 
+  [Guardrails in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) (Barreiras de proteção no AWS Control Tower) 
+  [Zero Trust architectures: An AWS perspective](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/) (Arquiteturas de confiança zero: uma perspectiva da AWS) 
+  [How to implement the principle of least privilege with CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/) (Como implementar o princípio de privilégio mínimo com o CloudFormation StackSets) 
+  [Controle de acesso baseado em atributos (ABAC)](https://docs.aws.amazon.com//latest/UserGuide/introduction_attribute-based-access-control.html?ref=wellarchitected) 
+ [Redução do escopo da política ao exibir a atividade do usuário](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html?ref=wellarchitected) 
+  [Visualizar acesso do cargo](https://docs.aws.amazon.com//latest/UserGuide/id_roles_manage_delete.html?ref=wellarchitected#roles-delete_prerequisites) 
+  [Use a marcação para organizar seu ambiente e gerar responsabilidade](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html?ref=wellarchitected) 
+  [Estratégias de marcação da AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/?ref=wellarchitected) 
+  [Marcação de recursos da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/quicksight-iam-identity-center/) 

 **Vídeos relacionados:** 
+  [Next-generation permissions management (Gerenciamento de permissões de última geração)](https://www.youtube.com/watch?v=8vsD_aTtuTo) 
+  [Zero Trust: An AWS perspective](https://www.youtube.com/watch?v=1p5G1-4s1r0) (Confiança zero: uma perspectiva da AWS) 
+  [How can I use permissions boundaries to limit users and roles to prevent privilege escalation?](https://www.youtube.com/watch?v=omwq3r7poek) (Como posso usar limites de permissões para limitar usuários e funções e evitar escalação do privilégio?) 

 **Exemplos relacionados:** 
+  [Lab: IAM permissions boundaries delegating role creation](https://wellarchitectedlabs.com/Security/300__Permission_Boundaries_Delegating_Role_Creation/README.html) (Laboratório: limites de permissões do IAM que delegam a criação de perfis) 
+  [Lab: IAM tag based access control for EC2](https://wellarchitectedlabs.com/Security/300__Tag_Based_Access_Control_for_EC2/README.html?ref=wellarchitected) (Laboratório: controle de acesso baseado em tags do IAM para EC2) 

# SEC03-BP03 Estabelecer processo de acesso de emergência
<a name="sec_permissions_emergency_process"></a>

 Crie um processo que permita acesso emergencial às suas workloads no caso improvável de um problema com seu provedor de identidades centralizado. 

 Você deve criar processos para diferentes modos de falha que possam resultar em um evento de emergência. Por exemplo, em circunstâncias normais, os usuários da sua força de trabalho são federados na nuvem usando um provedor de identidades centralizado ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)) para gerenciar as respectivas workloads. No entanto, se o provedor de identidades centralizado falhar ou a configuração da federação na nuvem for modificada, talvez os usuários de sua força de trabalho não consigam se federar na nuvem. Um processo de acesso de emergência permite que administradores autorizados acessem seus recursos de nuvem por meios alternativos (como uma forma alternativa de federação ou acesso direto do usuário) para corrigir problemas com sua configuração de federação ou workloads. O processo de acesso de emergência é usado até que o mecanismo normal de federação seja restaurado. 

 **Resultado desejado:** 
+  Você definiu e documentou os modos de falha que são considerados uma emergência: considere suas circunstâncias normais e os sistemas dos quais seus usuários dependem para gerenciar suas workloads. Pense em como cada uma dessas dependências pode falhar e causar uma situação de emergência. Você pode encontrar as perguntas e as práticas recomendadas no [Pilar Confiabilidade](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html) útil para identificar modos de falha e arquitetar sistemas mais resilientes com o objetivo de minimizar a probabilidade de falhas. 
+  Você documentou as etapas que devem ser seguidas para confirmar uma falha como emergência. Por exemplo, é possível exigir que os administradores de identidade confiram o status de seus provedores de identidade primário e de reserva e, se nenhum dos dois estiver disponível, declarar um evento de emergência por falha do provedor de identidades. 
+  Você definiu um processo de acesso de emergência específico de cada tipo de modo de emergência ou falha. Ser específico pode reduzir a tentação de seus usuários de abusar de um processo geral para todos os tipos de emergência. Seus processos de acesso de emergência descrevem as circunstâncias em que cada processo deve ser usado e, inversamente, as situações em que o processo não deve ser usado e apontam para processos alternativos que podem ser aplicados. 
+  Seus processos são bem documentados com instruções detalhadas e manuais que podem ser seguidos com rapidez e eficiência. Lembre-se de que um evento de emergência pode ser um momento estressante para os usuários e eles podem estar sob extrema pressão de tempo, portanto, projete o processo para ser o mais simples possível. 

 **Antipadrões comuns:** 
+  Você não tem processos de acesso de emergência bem documentados e bem testados. Os usuários não estão preparados para uma emergência e seguem processos improvisados quando surge um evento de emergência. 
+  Seus processos de acesso de emergência dependem dos mesmos sistemas (como um provedor de identidades centralizado) que seus mecanismos de acesso normais. Isso significa que a falha desse sistema pode afetar os mecanismos de acesso normal e de emergência e prejudicar sua capacidade de se recuperar da falha. 
+  Seus processos de acesso de emergência são usados em situações não emergenciais. Por exemplo, os usuários frequentemente usam de forma indevida os processos de acesso de emergência, pois acham mais fácil fazer alterações diretamente do que enviá-las por meio de um pipeline. 
+  Seus processos de acesso de emergência não geram logs suficientes para auditar os processos, ou os logs não são monitorados para alertar sobre o possível uso indevido dos processos. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Com processos de acesso de emergência bem documentados e testados, é possível reduzir o tempo gasto pelos usuários para responder e resolver um evento de emergência. Isso pode resultar em menos tempo de inatividade e maior disponibilidade dos serviços fornecidos aos seus clientes. 
+  Você pode rastrear cada solicitação de acesso de emergência e detectar e alertar sobre tentativas não autorizadas de uso indevido do processo para eventos não emergenciais. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida**: Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Esta seção fornece orientação para criar processos de acesso de emergência para vários modos de falha relacionados às workloads implantadas na AWS, começando com uma orientação comum que se aplica a todos os modos de falha e seguida por uma orientação específica com base no tipo de modo de falha. 

 **Orientação comum para todos os modos de falha** 

 Pense no seguinte ao projetar um processo de acesso de emergência para um modo de falha: 
+  Documente as pré-condições e as suposições do processo: quando o processo deve ou não ser usado. Isso ajuda a detalhar o modo de falha e documentar suposições, como o estado de outros sistemas relacionados. Por exemplo, o processo do Modo de falha 2 pressupõe que o provedor de identidades está disponível, mas a configuração na AWS foi modificada ou expirou. 
+  Pré-crie os recursos necessários para o processo de acesso de emergência ([SEC10-BP05](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html)). Por exemplo, crie previamente a Conta da AWS de acesso de emergência com IAM users e perfis e os perfis entre contas do IAM em todas as contas da workload. Isso verifica se esses recursos estão prontos e disponíveis quando ocorre um evento de emergência. Ao pré-criar recursos, você não depende das APIs do ambiente de gerenciamento da AWS [(usadas para criar e modificar recursos](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) da AWS) que podem ficar indisponíveis em caso de emergência. Além disso, ao pré-criar recursos do IAM, você não precisa contabilizar [possíveis atrasos devido à eventual consistência.](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency) 
+  Inclua processos de acesso de emergência como parte dos planos de gerenciamento de incidentes ([SEC10-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html)). Documente como os eventos de emergência são acompanhados e comunicados a outras pessoas na organização, como equipes de colegas, sua liderança e, quando aplicável, externamente a seus clientes e parceiros de negócios. 
+  Defina o processo de solicitação de acesso de emergência no sistema de fluxo de trabalho de solicitação de serviço existente, caso haja um. Normalmente, esses sistemas de fluxo de trabalho permitem criar formulários de admissão para coletar informações sobre a solicitação, acompanhar a solicitação em cada estágio do fluxo de trabalho e adicionar etapas de aprovação automatizadas e manuais. Relacione cada solicitação a um evento de emergência correspondente acompanhado no sistema de gerenciamento de incidentes. Ter um sistema uniforme para acessos de emergência permite que você acompanhe essas solicitações em um único sistema, analise as tendências de uso e melhore os processos. 
+  Verifique se os processos de acesso de emergência só podem ser iniciados por usuários autorizados e exigem aprovações dos colegas ou da gerência do usuário, conforme apropriado. O processo de aprovação deve operar de forma eficaz dentro e fora do horário comercial. Defina como as solicitações de aprovação permitirão aprovadores secundários se os aprovadores primários não estiverem disponíveis e forem encaminhadas para a cadeia de gerenciamento até serem aprovadas. 
+  Verifique se o processo gera logs e eventos de auditoria detalhados para tentativas bem-sucedidas e fracassadas de obter acesso de emergência. Monitore o processo de solicitação e o mecanismo de acesso de emergência para detectar uso indevido ou acessos não autorizados. Correlacione a atividade com eventos de emergência contínuos do sistema de gerenciamento de incidentes e alerte quando as ações ocorrerem fora dos períodos esperados. Por exemplo, você deve monitorar e alertar sobre atividades na Conta da AWS de acesso de emergência, pois ela nunca deve ser usada em operações normais. 
+  Teste os processos de acesso de emergência periodicamente para verificar se as etapas estão claras e garantir o nível correto de acesso com rapidez e eficiência. Os processos de acesso de emergência devem ser testados como parte das simulações de resposta a incidentes ([SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)) e testes de recuperação de desastres ([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)). 

 **Modo de falha 1: o provedor de identidades usado para federar na AWS não está disponível** 

 Conforme descrito em [SEC02-BP04 Contar com um provedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), recomendamos confiar em um provedor de identidades centralizado para federar os usuários de sua força de trabalho e conceder acesso a Contas da AWS. Você pode federar em várias Contas da AWS na organização da AWS usando o IAM Identity Center ou federar em Contas da AWS individuais usando o IAM. Nos dois casos, os usuários da força de trabalho se autenticam com seu provedor de identidades centralizado antes de serem redirecionados a um endpoint de login da AWS para SSO. 

 No caso improvável do provedor de identidades centralizado não estar disponível, os usuários da sua força de trabalho não poderão se federar nas Contas da AWS nem gerenciar as workloads. Nesse evento de emergência, é possível fornecer um processo de acesso de emergência para um pequeno grupo de administradores acessar Contas da AWS a fim de realizar tarefas essenciais que não podem esperar até que seus provedores de identidades centralizados estejam online novamente. Por exemplo, seu provedor de identidades fica indisponível por quatro horas e, durante esse período, você precisa modificar os limites superiores de um grupo do Amazon EC2 Auto Scaling em uma conta de produção para lidar com um aumento inesperado no tráfego de clientes. Seus administradores de emergência devem seguir o processo de acesso de emergência a fim de obter acesso à Conta da AWS de produção específica e fazer as alterações necessárias. 

 O processo de acesso de emergência depende de uma Conta da AWS de acesso de emergência pré-criada usada exclusivamente para acesso de emergência e tem recursos da AWS (como perfis do IAM e IAM users) para apoiar o processo de acesso de emergência. Durante as operações normais, ninguém deve acessar a conta de acesso de emergência, e você deve monitorar e alertar sobre o uso indevido dessa conta (para receber mais detalhes, consulte a seção Orientação comum anterior). 

 A conta de acesso de emergência tem perfis do IAM de acesso de emergência com permissões para assumir perfis entre contas nas Contas da AWS que exigem acesso de emergência. Esses perfis do IAM são pré-criados e configurados com políticas de confiança que confiam nos perfis do IAM da conta de emergência. 

 O processo de acesso de emergência pode usar uma das seguintes abordagens: 
+  Você pode pré-criar um conjunto de [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) para seus administradores de emergência na conta de acesso de emergência com senhas fortes e tokens de MFA associados. Esses IAM users têm permissões para assumir os perfis do IAM que permitem o acesso entre contas à Conta da AWS onde o acesso de emergência é necessário. Recomendamos criar o menor número possível de usuários e atribuir cada um a um único administrador de emergência. Durante uma emergência, um usuário administrador de emergência entra na conta de acesso de emergência usando sua senha e código de token MFA, muda para a função do IAM de acesso de emergência na conta de emergência e, por fim, muda para a função do IAM de acesso de emergência na conta da workload para realizar a ação de alteração de emergência. A vantagem dessa abordagem é que cada IAM user é atribuído a um administrador de emergência, e você pode saber qual usuário fez login analisando os eventos do CloudTrail. A desvantagem é que você precisa manter vários IAM users com as respectivas senhas de longa duração e tokens de MFA associados. 
+  Você pode usar o [usuário raiz da Conta da AWS de acesso de emergência](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) para entrar na conta de acesso de emergência, assumir o perfil do IAM para acesso de emergência e assumir o perfil entre contas na conta da workload. Recomendamos definir uma senha forte e vários tokens de MFA para o usuário raiz. Também recomendamos armazenar a senha e os tokens de MFA em um cofre de credenciais corporativo seguro que imponha autenticação e autorização fortes. Você deve proteger a senha e os fatores de redefinição de tokens de MFA: defina o endereço de e-mail da conta como uma lista de distribuição de e-mail monitorada pelos administradores de segurança na nuvem e o número de telefone da conta como um número de telefone compartilhado que também seja monitorado pelos administradores de segurança. A vantagem dessa abordagem é que há um conjunto de credenciais de usuário raiz para gerenciar. A desvantagem é que, como se trata de um usuário compartilhado, vários administradores podem fazer login como usuário raiz. Você deve fazer auditoria dos eventos de log do cofre corporativo para identificar qual administrador fez check-out da senha do usuário raiz. 

 **Modo de falha 2: a configuração do provedor de identidades na AWS foi modificada ou expirou** 

 Para permitir que os usuários de sua força de trabalho sejam federados nas Contas da AWS, você pode configurar o IAM Identity Center com um provedor de identidades externo ou criar um provedor de identidades do IAM ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)). Normalmente, você os configura importando um documento XML de metadados SAML fornecido pelo provedor de identidades. O documento XML de metadados inclui um certificado X.509 correspondente a uma chave privada que o provedor de identidades usa para assinar as declarações SAML. 

 Essas configurações no lado da AWS podem ser modificadas ou excluídas por engano por um administrador. Em outro cenário, o certificado X.509 importado para a AWS pode expirar, e um novo XML de metadados com um novo certificado ainda não foi importado para a AWS. Os dois cenários podem interromper a federação na AWS para os usuários de sua força de trabalho, ocasionando uma emergência. 

 Nesse evento de emergência, você pode fornecer aos seus administradores de identidade acesso à AWS para resolver os problemas de federação. Por exemplo, seu administrador de identidade usa o processo de acesso de emergência para fazer login na Conta da AWS de acesso de emergência, muda para um perfil na conta de administrador do Centro de Identidade e atualiza a configuração do provedor de identidades externo importando o documento XML de metadados SAML mais recente do provedor de identidades para reativar a federação. Depois que a federação for corrigida, os usuários da sua força de trabalho continuarão usando o processo operacional normal para federar em suas contas da workload. 

 Você pode seguir as abordagens detalhadas no Modo de falha 1 anterior para criar um processo de acesso de emergência. É possível conceder permissões de privilégio mínimo aos seus administradores de identidade a fim de acessar somente a conta de administrador do Centro de Identidade e realizar ações no Centro de Identidade nessa conta. 

 **Modo de falha 3: interrupção do Centro de Identidade** 

 No caso improvável de uma interrupção do IAM Identity Center ou da Região da AWS, recomendamos definir uma configuração que possa ser usada para conceder acesso temporário ao Console de gerenciamento da AWS. 

 O processo de acesso de emergência usa a federação direta do provedor de identidades no IAM em uma conta de emergência. Para receber detalhes sobre as considerações sobre o processo e o design, consulte [Configurar o acesso de emergência ao Console de gerenciamento da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html). 

### Etapas da implementação
<a name="implementation-steps"></a>

 **Etapas comuns para todos os modos de falha** 
+  Crie uma Conta da AWS dedicado aos processos de acesso de emergência. Pré-crie os recursos do IAM necessários na conta, como perfis do IAM ou IAM users e, opcionalmente, provedores de identidades do IAM. Além disso, crie previamente perfis do IAM entre contas nas Contas da AWS da workload com relacionamentos de confiança com os perfis do IAM correspondentes na conta de acesso de emergência. Você pode usar o [CloudFormation StackSets com AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) para criar esses recursos nas contas de membros de sua organização. 
+  Crie políticas de controle de serviço do AWS Organizations [(SCPS)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) para negar a exclusão e a modificação dos perfis do IAM entre contas nas Contas da AWS de membros. 
+  Ative o CloudTrail para a Conta da AWS de acesso de emergência e envie os eventos da trilha a um bucket central do S3 em sua Conta da AWS de coleção de logs. Se você estiver usando o AWS Control Tower para configurar e controlar seu ambiente de várias contas da AWS, todas as contas que você criar usando o AWS Control Tower ou inscrever no AWS Control Tower terão o CloudTrail ativado por padrão e serão enviadas a um bucket do S3 em uma Conta da AWS de arquivo de log dedicado. 
+  Monitore a atividade da conta de acesso de emergência criando regras do EventBridge que correspondam ao login do console e à atividade da API pelos perfis de emergência do IAM. Envie notificações ao seu centro de operações de segurança quando ocorrerem atividades fora de um evento de emergência contínuo acompanhado no sistema de gerenciamento de incidentes. 

 **Etapas adicionais para o Modo de falha 1: o provedor de identidades usado para federar na AWS não está disponível, e o Modo de falha 2: a configuração do provedor de identidades na AWS foi modificada ou expirou** 
+  Pré-crie recursos de acordo com o mecanismo escolhido para acesso de emergência: 
  +  **Usar IAM users:** pré-crie-os IAM users com senhas fortes e dispositivos de MFA associados. 
  +  **Usar o usuário raiz da conta de emergência:** configure o usuário raiz com uma senha forte e armazene a senha no seu cofre de credenciais corporativo. Associe vários dispositivos físicos de MFA ao usuário raiz e armazene os dispositivos em locais que possam ser acessados rapidamente pelos membros de sua equipe de administradores de emergência. 

 **Etapas adicionais para o Modo de falha 3: interrupção do Centro de Identidade** 
+  Conforme detalhado em [Configurar o acesso de emergência ao Console de gerenciamento da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html), na Conta da AWS de acesso de emergência, crie um provedor de identidades do IAM para ativar a federação direta de SAML a partir do provedor de identidades. 
+  Crie grupos de operações de emergência no IdP sem membros. 
+  Crie perfis do IAM correspondentes aos grupos de operações de emergência na conta de acesso de emergência. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [SEC02-BP04 Contar com um provedor de identidades centralizado](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html) 
+  [SEC03-BP02 Conceder acesso com privilégio mínimo](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html) 
+  [SEC10-BP02 Desenvolver planos de gerenciamento de incidentes](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html) 
+  [SEC10-BP07 Promover dias de jogo](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html) 

 **Documentos relacionados:** 
+  [Configurar o acesso de emergência ao Console de gerenciamento da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html) 
+  [Permitir que usuários federados do SAML 2.0 acessem o Console de gerenciamento da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html) 
+  [Acesso de emergência](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y) 
+  [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI) 

 **Exemplos relacionados:** 
+  [Perfil de acesso de emergência da AWS](https://github.com/awslabs/aws-break-glass-role) 
+  [AWS customer playbook framework](https://github.com/aws-samples/aws-customer-playbook-framework) 
+  [AWS incident response playbook samples](https://github.com/aws-samples/aws-incident-response-playbooks) 

# SEC03-BP04 Reduzir as permissões continuamente
<a name="sec_permissions_continuous_reduction"></a>

À medida que suas equipes determinarem o acesso de que precisam, remova as permissões desnecessárias e estabeleça processos de análise para obter permissões de privilégio mínimo. Monitore e remova continuamente identidades e permissões não utilizadas para acesso humano e de máquina.

 **Resultado desejado:** as políticas de permissão devem seguir o princípio de privilégio mínimo. À medida que os cargos e os perfis se tornem mais bem definidos, suas políticas de permissões precisam ser analisadas para remover permissões desnecessárias. Essa abordagem reduz o escopo do impacto caso as credenciais sejam expostas de forma acidental ou sejam acessadas sem autorização. 

 **Antipadrões comuns:** 
+  Usar como padrão a concessão de permissões de administrador aos usuários. 
+  Criar políticas permissivas demais, mas sem privilégios completos de administrador. 
+  Manter as políticas de permissão quando não são mais necessárias. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Enquanto as equipes e os projetos estiverem começando, políticas de permissão permissivas podem ser usadas para inspirar inovação e agilidade. Por exemplo, em um ambiente de desenvolvimento ou teste, os desenvolvedores podem receber acesso a uma ampla gama de serviços da AWS. Recomendamos avaliar o acesso de forma contínua e restringir o acesso somente àqueles serviços e ações de serviço necessários para concluir o trabalho atual. Recomendamos essa avaliação para identidades humanas e de máquina. Identidades de máquina, às vezes, denominadas contas de sistema ou serviço, são identidades que fornecem acesso da AWS a aplicações ou servidores. Esse acesso é especialmente importante em um ambiente de produção, em que as permissões excessivamente permissivas podem causar um grande impacto e expor dados dos clientes. 

 A AWS oferece vários métodos para ajudar a identificar usuários, perfis, permissões e credenciais não utilizados. A AWS também pode ajudar a analisar a atividade de acesso dos usuários e dos perfis do IAM, como chaves de acesso associadas, e o acesso aos recursos da AWS, como objetos em buckets do Amazon S3. A geração de políticas do AWS Identity and Access Management Access Analyzer pode auxiliar você a criar políticas de permissão restritivas com base nos serviços e nas ações reais com os quais uma entidade principal interage. [O controle de acesso baseado em atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) pode ajudar a simplificar o gerenciamento de permissões, pois você pode conceder permissões aos usuários utilizando os atributos deles em vez de anexar políticas de permissões diretamente a cada usuário. 

 **Etapas da implementação** 
+  **Utilizar o [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html): o ** IAM Access Analyzer ajuda a identificar os recursos na organização e nas contas, como buckets do Amazon Simple Storage Service (Amazon S3) ou perfis do IAM, que são [compartilhados com uma entidade externa](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html). 
+  **Utilizar a [geração de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html):** a geração de políticas do IAM Access Analyzer ajuda você a [criar políticas de permissão detalhadas com base em um usuário do IAM ou na atividade de acesso de um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks). 
+  **Determinar um cronograma e uma política de uso aceitáveis para usuários e perfis do IAM:** utilize o [carimbo de data e hora de último acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) para [identificar usuários e perfis não utilizados](https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/) e removê-los. Revise as informações de serviço e ação acessadas mais recentemente para identificar e [definir o escopo das permissões para usuários e perfis específicos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). Por exemplo, você pode usar as informações acessadas mais recentemente para identificar as ações específicas do Amazon S3 exigidas pelo perfil da aplicação e restringir o acesso do perfil apenas a essas ações. Os recursos de informações acessadas mais recentemente estão disponíveis no Console de gerenciamento da AWS e de maneira programática para permitir que você os incorpore aos fluxos de trabalho de infraestrutura e ferramentas automatizadas. 
+  **Considerar [o registro em log dos eventos de dados no AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html):** por padrão, o CloudTrail não registra eventos de dados, como atividade em nível de objeto do Amazon S3 (por exemplo, `GetObject` e `DeleteObject`) ou atividades de tabelas do Amazon DynamoDB (por exemplo, `PutItem` e `DeleteItem`). Considere ativar o registro em log desses eventos para determinar quais usuários e perfis precisam acessar objetos do Amazon S3 ou itens de tabelas do DynamoDB específicos. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Conceder privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+  [Remova credenciais desnecessárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+ [ O que é o AWS CloudTrail? ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+  [Trabalhando com políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 
+ [ Registrar em log e monitorar no DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [ Habilitar o log de eventos do CloudTrail para buckets e objetos do Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)
+ [ Obter relatórios de credenciais da sua Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)

 **Vídeos relacionados:** 
+  [Torne-se um mestre em políticas do IAM em 60 minutos ou menos](https://youtu.be/YQsK4MtsELU) 
+  [Separação de tarefas, privilégio mínimo, delegação e CI/CD](https://youtu.be/3H0i7VyTu70) 
+ [AWS re:Inforce 2022: Aprofundamento no AWS Identity and Access Management (IAM) ](https://www.youtube.com/watch?v=YMj33ToS8cI)

# SEC03-BP05 Definir barreiras de proteção de permissões para sua organização
<a name="sec_permissions_define_guardrails"></a>

 Estabeleça controles comuns que restrinjam o acesso a todas as identidades na organização. Por exemplo, é possível restringir o acesso a Regiões da AWS específicas ou impedir que os operadores excluam recursos comuns, como um perfil do IAM usado pela equipe de segurança central. 

 **Antipadrões comuns:** 
+ Execução de workloads em sua conta de administrador organizacional. 
+ Execução de workloads de produção e não produção na mesma conta. 

 **Nível de risco exposto se essa prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Com a expansão e o gerenciamento de workloads adicionais na AWS, você deve separá-las usando contas e gerenciá-las usando o AWS Organizations. Recomendamos que você estabeleça barreiras de proteção de permissões comuns que restrinjam o acesso a todas as identidades na sua organização. Por exemplo, você pode restringir o acesso a Regiões da AWS específicas ou impedir que a equipe exclua recursos comuns, como um perfil do IAM usado pela equipe de segurança central. 

 Você pode começar implementando exemplos de políticas de controle de serviço, como impedir que os usuários desabilitem os principais serviços. As SCPs usam a linguagem de políticas do IAM e permitem que você estabeleça controles aos quais todas as entidades principais (usuários e perfis) do IAM aderem. Você pode restringir o acesso a ações de serviço, recursos específicos e com base em condições específicas para atender às necessidades de controle de acesso de sua organização. Se necessário, você pode definir exceções para suas barreiras de proteção. Por exemplo, você pode restringir ações de serviço para todas as entidades do IAM na conta, exceto para um perfil de administrador específico. 

 Recomendamos evitar a execução de workloads em sua conta de gerenciamento. A conta de gerenciamento deve ser usada para gerir e implantar barreiras de proteção de segurança que afetarão as contas-membro. Alguns serviços da AWS permitem o uso de uma conta de administrador delegada. Quando disponível, você deve usar essa conta delegada em vez da conta de gerenciamento. Você deve limitar estritamente o acesso à conta de administrador organizacional. 

O uso de uma estratégia de várias contas permite ter maior flexibilidade na aplicação de barreiras de proteção às suas workloads. O AWS Security Reference Architecture dá orientações prescritivas sobre como projetar a estrutura da conta. Os serviços da AWS, como o AWS Control Tower, fornece recursos para gerenciar centralmente os controles de prevenção e detecção em sua organização. Defina um objetivo claro para cada conta ou UO em sua organização e limite os controles de acordo com esse objetivo. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Organizations](https://aws.amazon.com/organizations/) 
+ [Service control policies (SCPs) (Políticas de controle de serviços (SCPs))](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 
+ [Get more out of service control policies in a multi-account environment (Aproveite ao máximo as políticas de controle de serviços em um ambiente de várias contas)](https://aws.amazon.com/blogs/security/get-more-out-of-service-control-policies-in-a-multi-account-environment/) 
+ [AWS Security Reference Architecture (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html) 

 **Vídeos relacionados:** 
+ [Enforce Preventive Guardrails using Service Control Policies (Aplique barreiras de proteção preventivas usando políticas de controle de serviços)](https://www.youtube.com/watch?v=mEO05mmbSms) 
+  [Building governance at scale with AWS Control Tower (Criação de governança em escala com o AWS Control Tower)](https://www.youtube.com/watch?v=Zxrs6YXMidk) 
+  [AWS Identity and Access Management deep dive (Análise aprofundada do AWS Identity and Access Management)](https://www.youtube.com/watch?v=YMj33ToS8cI) 

# SEC03-BP06 Gerenciar o acesso com base no ciclo de vida
<a name="sec_permissions_lifecycle"></a>

 Integre controles de acesso ao ciclo de vida do operador e da aplicação e ao seu provedor de federação centralizado. Por exemplo, remova o acesso do usuário que sair da organização ou mudar de funções. 

À medida que você gerencia cargas de trabalho usando contas separadas, haverá casos em que você precisará compartilhar recursos entre essas contas. Recomendamos que você compartilhe recursos usando o [AWS Resource Access Manager (AWS RAM)](http://aws.amazon.com/ram/). Esse serviço permite que você compartilhe, com facilidade e segurança, os recursos da AWS dentro da AWS Organizations e das unidades organizacionais. Usando o AWS RAM, o acesso a recursos compartilhados é concedido ou revogado automaticamente à medida que as contas são movidas para dentro e para fora da organização ou da unidade organizacional com a qual são compartilhadas. Isso ajuda a garantir que os recursos sejam compartilhados apenas com as contas que você determinar.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Ciclo de vida de acesso de usuário: implemente uma política de ciclo de vida de acesso para novos usuários, alterações de função de trabalho e usuários que saem, para que apenas os usuários atuais tenham acesso. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AttributeControle de acesso baseado em atributos (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [Grant least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+  [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 
+  [Remova credenciais desnecessárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+  [Trabalhando com políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 

 **Vídeos relacionados:** 
+  [Become an IAM Policy Master in 60 Minutes or Less (Torne-se um mestre em políticas do IAM em 60 minutos ou menos)](https://youtu.be/YQsK4MtsELU) 
+  [Separation of Duties, Least Privilege, Delegation, and CI/CD (Separação de tarefas, privilégio mínimo, delegação e CI/CD)](https://youtu.be/3H0i7VyTu70) 

# SEC03-BP07 Analisar o acesso público e entre contas
<a name="sec_permissions_analyze_cross_account"></a>

Monitore continuamente as descobertas que destacam o acesso público e entre contas. Reduza o acesso público e o acesso entre contas somente aos recursos específicos que exigem esse acesso.

 **Resultado desejado:** saber quais de seus recursos da AWS são compartilhados e com quem. Monitorar e auditar continuamente seus recursos compartilhados para verificar se eles são compartilhados com apenas entidades principais autorizadas. 

 **Antipadrões comuns:** 
+  Não manter um inventário dos recursos compartilhados. 
+  Não seguir um processo de aprovação do acesso público ou entre contas aos recursos. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Se a sua conta estiver no AWS Organizations, você poderá conceder acesso aos recursos à toda a organização, a unidades organizacionais específicas ou a contas individuais. Se sua conta não for membro de uma organização, você poderá compartilhar recursos com contas individuais. Você pode conceder acesso direto entre contas usando políticas baseadas em recursos, por exemplo, [políticas de buckets do Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) ou permitindo que uma identidade principal em outra conta assuma um perfil do IAM em sua conta. Ao utilizar políticas de recursos, verifique se o acesso é concedido apenas a entidades principais autorizadas. Defina um processo para aprovar todos os recursos que devem ser acessíveis publicamente. 

 O [AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) utiliza [segurança demonstrável](https://aws.amazon.com/security/provable-security/) para identificar todos os caminhos de acesso a um recurso de fora de sua conta. Ele revisa as políticas de recursos continuamente e relata descobertas de acesso público e entre contas para facilitar a análise de acesso potencialmente amplo. Considere configurar o IAM Access Analyzer com o AWS Organizations para verificar se você tem visibilidade a todas as suas contas. O IAM Access Analyzer também possibilita que você [visualize descobertas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html) antes de implantar permissões de recursos. Isso permite validar que as alterações de política concedam apenas o acesso público e entre contas pretendido aos seus recursos. Ao projetar o acesso a várias contas, é possível utilizar [políticas de confiança](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) para controlar em quais casos um perfil pode ser assumido. Por exemplo, você pode usar a chave de condição [`PrincipalOrgId` para negar uma tentativa de assumir um perfil de fora de seu AWS Organizations](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/). 

 [O AWS Config pode relatar recursos](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) configurados incorretamente, e por meio de verificações de politica do AWS Config, pode detectar recursos que tenham acesso público configurado. Serviços, como [AWS Control Tower](https://aws.amazon.com/controltower/) e [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) simplificam a implantação de controles de detecção e barreiras de proteção nos AWS Organizations para identificar e corrigir recursos publicamente expostos. Por exemplo, o AWS Control Tower tem uma barreira de proteção gerenciada que pode detectar se algum [snapshot do Amazon EBS é restaurado por Contas da AWS](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html). 

 **Etapas da implementação** 
+  **Pensar em ativar o [AWS Config para AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html):** o AWS Config permite que você agregue as descobertas de várias contas em um AWS Organizations em uma conta de administrador delegada. Isso oferece uma visão abrangente e permite que você [implante o Regras do AWS Config nas contas para detectar recursos acessíveis ao público](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html). 
+  **Configurar o AWS Identity and Access Management Access Analyzer** o IAM Access Analyzer ajuda a identificar os recursos na organização e nas contas, como buckets do Amazon S3 ou perfis do IAM, que são [compartilhados com uma entidade externa](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html). 
+  **Usar autocorreção no AWS Config para responder a alterações na configuração do acesso público de buckets do Amazon S3:** [é possível reativar automaticamente as configurações de acesso público de bloco para buckets do Amazon S3](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/). 
+  **Implementar o monitoramento e os alertas para identificar se os buckets do Amazon S3 se tornaram públicos:** é necessário ter o [monitoramento e os alertas](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/) implementados para identificar quando o acesso público de blocos do Amazon S3 foi desativado e se os buckets do Amazon S3 se tornaram públicos. Além disso, se você estiver usando o AWS Organizations, poderá criar uma [política de controle de serviços](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) que impeça alterações nas políticas de acesso público do Amazon S3. O AWS Trusted Advisor confere se há buckets do Amazon S3 com permissões de acesso abertas. As permissões de bucket que concedem, upload ou excluem acesso a todos criam possíveis problemas de segurança, pois permitem que qualquer pessoa adicione, modifique ou remova itens em um bucket. A verificação do Trusted Advisor examina as permissões de bucket explícitas e as políticas de bucket associadas que podem substituir as permissões de bucket. Você também pode utilizar o AWS Config para monitorar seus buckets do Amazon S3 para acesso público. Para ter mais informações, consulte [Como usar o AWS Config para monitorar e responder a buckets do Amazon S3 que possibilitam acesso público](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/). Ao revisar o acesso, é importante considerar quais tipos de dados estão contidos em buckets do Amazon S3. O [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) ajuda a descobrir e proteger dados sigilosos, como PII, PHI e credenciais, como chaves privadas ou da AWS. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Usar o AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [ Biblioteca de controles do AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html)
+  [Norma de práticas de segurança básicas da AWS](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+  [Regras gerenciadas do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html) 
+  [Referência de verificação do AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html) 
+ [ Monitorar resultados da verificação do AWS Trusted Advisor com o Amazon EventBridge ](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html)
+ [ Gerenciar regras do AWS Config em todas as contas de sua organização ](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)
+ [AWS Config e AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)

 **Vídeos relacionados:** 
+ [Práticas recomendadas para proteger seu ambiente de várias contas](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [Análise aprofundada do IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0)

# SEC03-BP08 Compartilhar recursos com segurança em sua organização
<a name="sec_permissions_share_securely"></a>

À medida que o número de workloads aumenta, talvez você precise compartilhar o acesso aos recursos nessas workloads ou fornecer os recursos várias vezes nas contas. Você pode ter estruturas para fragmentar seu ambiente, como ter ambientes de desenvolvimento, teste e produção. No entanto, ter estruturas de separação não limita o compartilhamento seguro. Ao compartilhar componentes que se sobrepõem, você pode reduzir a sobrecarga operacional e possibilitar uma experiência consistente sem precisar adivinhar o que ignorou ao criar o mesmo recurso várias vezes. 

 **Resultado desejado:** minimizar o acesso acidental utilizando métodos seguros para compartilhar recursos com sua organização e ajudar com sua iniciativa de prevenção de perda de dados. Reduza sua sobrecarga operacional em comparação com o gerenciamento de componentes individuais, reduza os erros gerados pela criação manual do mesmo componente várias vezes e aumente a escalabilidade de suas workloads. É possível se beneficiar da redução de tempo para a resolução em cenários de falhas em vários pontos e aumentar sua confiança na determinação de quando um componente não é mais necessário. Para ter orientações prescritivas sobre como analisar recursos compartilhados externamente, consulte [SEC03-BP07 Analisar o acesso público e entre contas](sec_permissions_analyze_cross_account.md). 

 **Antipadrões comuns:** 
+  Falta de um processo para monitorar de forma contínua e alertar automaticamente sobre o compartilhamento externo inesperado. 
+  Falta de referência sobre o que deve ou não ser compartilhado. 
+  Ter como padrão uma política amplamente aberta em vez de compartilhar explicitamente quando necessário. 
+  Criar manualmente recursos básicos que se sobrepõem quando necessário. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Projete seus controles e padrões de acesso para reger o consumo de recursos compartilhados com segurança e somente com entidades confiáveis. Monitore recursos compartilhados e revise o acesso a eles de forma contínua e seja alertado sobre o compartilhamento inadequado ou inesperado. Leia [Analisar o acesso público e entre contas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html) para ajudar você a estabelecer a governança a fim de reduzir o acesso externo apenas aos recursos que precisem dele e estabelecer um processo para monitorar de forma contínua e alertar automaticamente. 

 O compartilhamento entre contas no AWS Organizations é compatível com [uma série de serviços da AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html), como o [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html), [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html) e o [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html). Esses serviços possibilitam compartilhar os dados em uma conta central, acessá-los ou gerenciar recursos e dados dessa conta. Por exemplo, o AWS Security Hub CSPM pode transferir as descobertas de contas individuais para uma conta central onde é possível visualizar todas elas. O AWS Backup pode realizar um backup de um recurso e compartilhá-lo entre contas. É possível utilizar o [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) para compartilhar outros recursos comuns, como [sub-redes de VPC e anexos do Transit Gateway](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc), [AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) ou pipelines [Amazon SageMaker AI](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker). 

 Para restringir sua conta para somente compartilhar recursos em sua organização, utilize [políticas de controle de serviços (SCPs)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) para impedir o acesso a entidades principais externas. Ao compartilhar recursos, combine controles baseados em identidade e controles de rede para [criar um perímetro de dados para sua organização](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) a fim de ajudar a proteger contra o acesso acidental. Um perímetro de dados é um conjunto de barreiras de proteção preventivas que ajudam a garantir que apenas suas identidades confiáveis acessem recursos confiáveis das redes esperadas. Esses controles impõem limites apropriados sobre quais recursos podem ser compartilhados e impedir o compartilhamento ou a exposição de recursos que não devem ser permitidos. Por exemplo, como parte de um perímetro de dados, é possível usar políticas de endpoint de VPC e a condição `AWS:PrincipalOrgId` para garantir que as identidades que acessam seus buckets do Amazon S3 pertençam à sua organização. É importante observar que as [SCPs não se aplicam a perfis vinculados a serviço (LSR) nem a entidades principais de serviços da AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions). 

 Ao utilizar o Amazon S3, [desative as ACLs de seu bucket do Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) e utilize políticas do IAM para definir o controle de acesso. Para [restringir o acesso a uma origem do Amazon S3](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) a partir do [Amazon CloudFront](https://aws.amazon.com/cloudfront/), migre da identidade do acesso de origem (OAI) para um controle de acesso de origem (OAC), que é compatível com recursos adicionais, por exemplo, a criptografia do lado do servidor com o [AWS Key Management Service](https://aws.amazon.com/kms/). 

 Em alguns casos, convém permitir o compartilhamento de recursos fora de sua organização ou conceder a terceiros acesso aos seus recursos. Para ter orientações prescritivas sobre o gerenciamento de permissões para compartilhar recursos externamente, consulte [Gerenciamento de permissões](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html). 

 **Etapas da implementação** 

1.  **Utilize o AWS Organizations.** 

    O AWS Organizations é um serviço de gerenciamento de contas que permite consolidar várias Contas da AWS em uma organização que você cria e gerencia centralmente. É possível agrupar suas contas em unidades organizacionais (UOs) e anexar políticas diferentes a cada UO a fim de ajudar a atender às suas necessidades orçamentárias, de segurança e conformidade. Também é possível controlar como serviços de inteligência artificial (IA) e machine learning (ML) da AWS podem coletar e armazenar dados e usar o gerenciamento de várias contas dos serviços da AWS integrados ao Organizations. 

1.  **Integre o AWS Organizations aos serviços da AWS.** 

    Ao ativar um serviço da AWS para realizar tarefas em seu nome nas contas membros de sua organização, o AWS Organizations cria um perfil vinculado a serviço do IAM para esse serviço em cada conta membro. Você deve gerenciar o acesso confiável usando o Console de gerenciamento da AWS, as APIs da AWS ou a AWS CLI. Para ter orientações prescritivas sobre como ativar o acesso confiável, consulte [Usar o AWS Organizations com outros serviços da AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html) e [Serviços da AWS que podem ser usados com o Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html). 

1.  **Estabeleça um perímetro de dados.** 

    O perímetro da AWS, geralmente, é representado como uma organização gerenciada pelo AWS Organizations. Junto com redes e sistemas on-premises, o acesso a recursos da AWS é o que muitos consideram o perímetro de My AWS. O objetivo do perímetro é garantir que o acesso seja permitido se a identidade e o recurso forem confiáveis e a rede for esperada. 

   1.  Defina e implante os perímetros. 

       Siga as etapas descritas em [Implementação do perímetro](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html) do whitepaper Criar um perímetro na AWS para cada condição de autorização. Para ter orientações prescritivas sobre como proteger a camada de rede, consulte [Proteção de redes](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-networks.html). 

   1.  Monitore e alerte de forma contínua. 

       O [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) ajuda a identificar os recursos na organização e nas contas que são compartilhados com entidades externas. É possível integrar o [IAM Access Analyzer ao AWS Security Hub CSPM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-securityhub-integration.html) para enviar e agregar as descobertas para um recurso do IAM Access Analyzer para o Security Hub CSPM a fim de ajudar a analisar o procedimento de segurança de seu ambiente. Para ativar a integração, ative o IAM Access Analyzer e o Security Hub CSPM em cada região em cada conta. Também é possível utilizar o Regras do AWS Config para fazer auditoria da configuração e alertar a parte adequada utilizando o [Amazon Q Developer in chat applications com o AWS Security Hub CSPM](https://aws.amazon.com/blogs/security/enabling-aws-security-hub-integration-with-aws-chatbot/). Depois, você pode utilizar [Documentos de automação do AWS Systems Manager](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) para corrigir os recursos sem conformidade. 

   1.  Para ter orientações prescritivas sobre como monitorar e alertar de forma contínua sobre recursos compartilhados externamente, consulte [Analisar o acesso público e entre contas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html). 

1.  **Utilize o compartilhamento de recursos em serviços da AWS e restrinja-o adequadamente.** 

    Muitos serviços da AWS possibilitam compartilhar recursos com outra conta ou almejar um recurso em outra conta, como [Imagens de máquina da Amazon (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) e [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html). Restrinja a API `ModifyImageAttribute` para especificar as contas confiáveis com as quais compartilhar a AMI. Especifique a condição `ram:RequestedAllowsExternalPrincipals` ao utilizar o AWS RAM para restringir o compartilhamento somente à sua organização, a fim de ajudar a impedir o acesso de identidades não confiáveis. Para ter orientações prescritivas e considerações, consulte [Compartilhamento de recursos e destinos externos](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html). 

1.  **Utilize o AWS RAM para compartilhar com segurança em uma conta ou com outras Contas da AWS.** 

    O [AWS RAM](https://aws.amazon.com/ram/) ajuda você a compartilhar com segurança os recursos criados com perfis e usuários em sua conta e com outras Contas da AWS. Em um ambiente de várias contas, o AWS RAM possibilita criar um recurso uma vez e compartilhá-lo com outras contas. Essa abordagem ajuda a reduzir sua sobrecarga operacional ao oferecer consistência, visibilidade e capacidade de auditoria por meio de integrações com o Amazon CloudWatch e o AWS CloudTrail, o que você não recebe ao utilizar o acesso entre contas. 

    Se você tiver recursos compartilhados anteriormente com o uso de uma política baseada em recurso, é possível utilizar a API [https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) ou equivalente a fim de promover o compartilhamento de recursos para um compartilhamento completo de recursos do AWS RAM. 

    Em alguns casos, convém realizar etapas adicionais para compartilhar recursos. Por exemplo, para compartilhar um snapshot criptografado, é necessário [compartilhar uma chave do AWS KMS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC03-BP07 Analisar o acesso público e entre contas](sec_permissions_analyze_cross_account.md) 
+  [SEC03-BP09 Compartilhar recursos com segurança com terceiros](sec_permissions_share_securely_third_party.md) 
+  [SEC05-BP01 Criar camadas de rede](sec_network_protection_create_layers.md) 

 **Documentos relacionados:** 
+ [Proprietário do bucket concede permissão entre contas a objetos que não possui](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [Como usar políticas de confiança com o IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Criar um perímetro de dados na AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [Como usar um ID externo ao conceder acesso aos seus recursos da AWS para terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [ Serviços da AWS que podem ser usados com o AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [ Estabelecer um perímetro de dados na AWS: permitir apenas que identidades confiáveis acessem os dados da empresa ](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)

 **Vídeos relacionados:** 
+ [Acesso granular com o AWS Resource Access Manager](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [Como proteger seu perímetro de dados com endpoints da VPC](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [ Estabelecer um perímetro de dados na AWS](https://www.youtube.com/watch?v=SMi5OBjp1fI)

 **Ferramentas relacionadas:** 
+ [ Exemplos de política de perímetro de dados ](https://github.com/aws-samples/data-perimeter-policy-examples)

# SEC03-BP09 Compartilhar recursos com segurança com terceiros
<a name="sec_permissions_share_securely_third_party"></a>

 A segurança de seu ambiente de nuvem não é interrompida em sua organização. Sua organização pode contar com terceiros para gerenciar uma parte de seus dados. O gerenciamento de permissões para o sistema gerenciado por terceiros deve seguir a prática de acesso just-in-time utilizando o princípio de privilégio mínimo com credenciais temporárias. A trabalhar em parceria com terceiros, é possível reduzir o escopo do impacto e o risco de acesso acidental. 

 **Resultado desejado:** credenciais do AWS Identity and Access Management (IAM) de longo prazo, chaves de acesso do IAM e chaves secretas associadas a um usuário podem ser usadas por qualquer pessoa desde que as credenciais sejam válidas e ativas. O uso de um perfil do IAM e credenciais temporárias ajuda você a melhorar seu procedimento de segurança geral reduzindo o esforço para manter credenciais de longo prazo, inclusive o gerenciamento e a sobrecarga operacional dessas informações sigilosas. Ao utilizar um identificador universalmente exclusivo (UUID) para o ID externo na política de confiança do IAM e manter as políticas do IAM anexadas ao perfil do IAM sob seu controle, é possível fazer auditoria e garantir que o acesso concedido a terceiros não seja permissivo demais. Para ter orientações prescritivas sobre como analisar recursos compartilhados externamente, consulte [SEC03-BP07 Analisar o acesso público e entre contas](sec_permissions_analyze_cross_account.md). 

 **Antipadrões comuns:** 
+  Utilizar a política de confiança do IAM padrão sem condições. 
+  Utilizar credenciais e chaves de acesso de longo prazo do IAM. 
+  Reutilizar IDs externos. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Talvez você deseje permitir o compartilhamento de recursos fora do AWS Organizations ou conceder a terceiros acesso à sua conta. Por exemplo, um parceiro (terceiros) pode oferecer uma solução de monitoramento que precise acessar recursos em sua conta. Nesses casos, crie um perfil entre contas do IAM somente com os privilégios necessários para o parceiro. Além disso, defina uma política de segurança com o uso da [condição de ID externo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). Ao utilizar um ID externo, você ou o parceiro pode gerar um ID exclusivo para cada cliente, terceiros ou locação. O ID exclusivo não deve ser controlado por ninguém, exceto por você, depois de criado. O parceiro deve implementar um processo para relacionar o ID externo ao cliente de forma segura, auditável e reproduzível. 

 Também é possível usar o [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) para gerenciar perfis do IAM para aplicações fora do AWS que utilizam APIs da AWS. 

 Se o parceiro não precisar mais de acesso ao seu ambiente, remova o perfil. Evite fornecer credenciais de longo prazo para terceiros. Esteja ciente de outros serviços da AWS compatíveis com o compartilhamento. Por exemplo, o AWS Well-Architected Tool possibilita o [compartilhamento de uma workload](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) com outras Contas da AWS, e o [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) ajuda você a compartilhar com segurança um recurso da AWS que você possua com outras contas. 

 **Etapas da implementação** 

1.  **Utilize perfis entre contas para fornecer acesso a contas externas.** 

    Os [perfis entre contas](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) reduzem a quantidade de informações sigilosas armazenadas por contas externas e terceiros para atender aos clientes. Os perfis entre contas possibilitam a você conceder acesso a recursos da AWS em sua conta de forma segura a terceiros, como AWS Partners ou outras contas em sua organização e, ao mesmo tempo, manter a capacidade de gerenciar e auditar esse acesso. 

    O parceiro pode oferecer serviço a você a partir de uma infraestrutura híbrida ou, como alternativa, extrair dados de um local externo. O [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) ajuda você a possibilitar que workloads de terceiros interajam com segurança com suas workloads da AWS e reduzir ainda mais a necessidade de credenciais de longo prazo. 

    Você não deve usar credenciais ou chaves de acesso de longo prazo associadas a usuários para conceder acesso a contas externas. Em vez disso, utilize perfis entre contas para conceder acesso entre contas. 

1.  **Utilize um ID externo com terceiros.** 

    O uso de um [ID externo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) possibilita designar quem pode assumir um perfil em uma política de confiança do IAM. A política de confiança pode exigir que o usuário que assume o perfil imponha a condição e o destino no qual ele está operando. Ele também fornece uma maneira para que o proprietário da conta permita que a função seja assumida somente em circunstâncias específicas. A função principal do ID externo é resolver e evitar o problema de [substituto confuso](https://docs.aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/). 

    Utilize um ID externo se você for proprietário de uma Conta da AWS e tiver configurado um perfil para terceiros que acesse outras Contas da AWS além da sua, ou quando você pode assumir perfis em nome de clientes diferentes. Trabalhe com terceiros ou a AWS Partner para estabelecer uma condição de ID externo a ser incluída na política de confiança do IAM. 

1.  **Utilize IDs externos universalmente exclusivos.** 

    Implemente um processo que gere um valor exclusivo aleatório para um ID externo, como um identificador universalmente exclusivo (UUID). Um parceiro que reutilize IDs externos entre diferentes clientes não resolve o problema de substituto confuso porque o cliente A pode ser capaz de visualizar dados do cliente B utilizando o ARN do perfil do cliente B junto com o ID externo duplicado. Em um ambiente de vários locatários, em que um parceiro atende a vários clientes com diferentes Contas da AWS, o parceiro deve usar um ID exclusivo diferente como o ID externo de cada Conta da AWS. O parceiro é responsável por detectar IDs externos duplicados e mapear de forma segura cada cliente ao seu respectivo ID externo. O parceiro deve testar para verificar se ele pode assumir o perfil somente ao especificar o ID externo. O parceiro deve evitar armazenar o ARN do perfil do cliente e o ID externo até que este seja necessário. 

    O ID externo não é tratado como segredo, mas ele não pode ser um valor facilmente dedutível, como um número de telefone, um nome ou o ID da conta. Torne o ID externo um campo somente leitura de forma que o ID externo não possa ser alterado com o fim de representar a configuração. 

    Você ou o parceiro podem gerar o ID externo. Defina um processo para determinar quem é responsável pela geração do ID. Seja qual for a entidade que crie o ID externo, o parceiro impõe a exclusividade e os formatos de forma consistente entre os clientes. 

1.  **Deprecie credenciais de longo prazo fornecidas pelo cliente.** 

    Deprecie o uso de credenciais de longo prazo e use perfis entre clientes ou o IAM Roles Anywhere. Se você precisar utilizar credenciais de longo prazo, estabeleça um plano para migrar para um acesso baseado em perfil. Para obter detalhes sobre como gerenciar chaves, consulte [Gerenciamento de identidades](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html). Trabalhe também com a equipe de sua Conta da AWS e o parceiro para estabelecer um runbook de mitigação de riscos. Para ter orientações prescritivas sobre como responder e mitigar o impacto em potencial do incidente de segurança, consulte [Resposta a incidentes](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html). 

1.  **Verifique se a configuração tem orientações prescritivas ou é automatizada.** 

    A política criada para acesso entre contas em suas contas deve seguir o [princípio de privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). O parceiro deve fornecer um documento de política de perfil ou um mecanismo de configuração automatizada que utilize um modelo do AWS CloudFormation ou um equivalente para você. Isso reduz a chance de erros associados à criação manual de políticas e oferece uma trilha auditável. Para ter mais informações sobre como usar um modelo do CloudFormation para criar perfis entre contas, consulte [Perfis entre contas](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/). 

    O parceiro deve fornecer um mecanismo de configuração automatizado e auditável. No entanto, ao utilizar o documento de política de perfis que descreve o acesso necessário, você deve automatizar a configuração do perfil. Com um modelo do CloudFormation ou equivalente, você deve monitorar alterações com detecção de desvios como parte da prática de auditoria. 

1.  **Considere alterações.** 

    Sua estrutura de contas, sua necessidade de terceiros ou a oferta de serviço pode ser alterada. Você deve antecipar alterações e falhas e planejar adequadamente com as pessoas, o processo e a tecnologia corretos. Audite o nível de acesso que você concede periodicamente e implemente métodos de detecção para alertar você de alterações inesperadas. Monitore e audite o uso do perfil e o datastore dos IDs externos. Você deve estar preparado para revogar o acesso de terceiros, seja de forma temporária ou permanente, como resultado de alterações ou padrões de acesso inesperados. Além disso, meça o impacto de sua operação de revogação, inclusive o tempo para realizá-la, as pessoas envolvidas, o custo e o impacto de outros recursos. 

    Para ter orientações prescritivas sobre métodos de detecção, consulte as [Práticas recomendadas de detecção](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC02-BP02 Usar credenciais temporárias](sec_identities_unique.md) 
+  [SEC03-BP05 Definir barreiras de proteção de permissões para sua organização](sec_permissions_define_guardrails.md) 
+  [SEC03-BP06 Gerenciar o acesso com base no ciclo de vida](sec_permissions_lifecycle.md) 
+  [SEC03-BP07 Analisar o acesso público e entre contas](sec_permissions_analyze_cross_account.md) 
+ [ SEC04 Detecção ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)

 **Documentos relacionados:** 
+ [ Proprietário do bucket concede permissão entre contas a objetos que não possui ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [ Como usar políticas de confiança com os perfis do IAM ](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [ Delegar acesso entre Contas da AWS usando funções do IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [ Como acesso recursos em outra Conta da AWS usando o IAM? ](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/)
+ [ Práticas recomendadas de segurança no IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [ Lógica de avaliação de política entre contas ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [ Como usar um ID externo ao conceder acesso a seus recursos da AWS a terceiros ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [ Coletar informações de recursos do AWS CloudFormation criados em contas externas com recursos personalizados ](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)
+ [ Usar ID externo com segurança para acessar contas da AWS pertencentes a outros ](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)
+ [Estender perfis do IAM fora do IAM com IAM Roles Anywhere) ](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)

 **Vídeos relacionados:** 
+ [ Como permito que usuários ou perfis em uma Conta da AWS separada acessem minha Conta da AWS? ](https://www.youtube.com/watch?v=20tr9gUY4i0)
+ [AWS re:Invent 2018: Torne-se um mestre em políticas do IAM em 60 minutos ou menos ](https://www.youtube.com/watch?v=YQsK4MtsELU)
+ [AWSPráticas recomendadas do IAM e decisões de design ](https://www.youtube.com/watch?v=xzDFPIQy4Ks)

 **Exemplos relacionados:** 
+ [ Well-Architected Lab: Assumir perfil do IAM entre contas do Lambda (Nível 300)](https://www.wellarchitectedlabs.com/security/300_labs/300_lambda_cross_account_iam_role_assumption/)
+ [ Configurar o acesso entre contas ao Amazon DynamoDB ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)
+ [AWS STS Network Query Tool ](https://github.com/aws-samples/aws-sts-network-query-tool)

# Detecção
<a name="a-detective-controls"></a>

**Topics**
+ [SEGURANÇA 4. Como detectar e investigar eventos de segurança?](sec-04.md)

# SEGURANÇA 4. Como detectar e investigar eventos de segurança?
<a name="sec-04"></a>

Capture e analise eventos de logs e métricas para gerar visibilidade. Tome medidas em eventos de segurança e potenciais ameaças para ajudar a proteger sua carga de trabalho.

**Topics**
+ [SEC04-BP01 Configurar registro em log de serviço e aplicação](sec_detect_investigate_events_app_service_logging.md)
+ [SEC04-BP02 Analisar logs, descobertas e métricas de forma centralizada](sec_detect_investigate_events_analyze_all.md)
+ [SEC04-BP03 Automatizar a resposta a eventos](sec_detect_investigate_events_auto_response.md)
+ [SEC04-BP04 Implementar eventos de segurança acionáveis](sec_detect_investigate_events_actionable_events.md)

# SEC04-BP01 Configurar registro em log de serviço e aplicação
<a name="sec_detect_investigate_events_app_service_logging"></a>

Retenha logs de eventos de segurança de serviços e aplicações. Esse é um princípio fundamental de segurança para auditoria, investigações e casos de uso operacionais e um requisito de segurança comum orientado por padrões, políticas e procedimentos de governança, risco e conformidade (GRC).

 **Resultado desejado:** uma organização deve ser capaz de recuperar de forma confiável e consistente logs de ventos de segurança de serviços e aplicações da AWS de modo pontual quando necessário a fim de cumprir um processo ou obrigação interna, como resposta a incidentes de segurança. Considere centralizar os logs para ter melhores resultados operacionais. 

 **Antipadrões comuns:** 
+  Os logs são armazenados de forma perpétua ou excluídos muito precocemente. 
+  Todos podem acessar os logs. 
+  Contar inteiramente com processos manuais para uso e governança de logs. 
+  Armazenar todos os tipos de log em caso de necessidade. 
+  Conferir a integridade dos logs apenas quando necessário. 

 **Benefícios do estabelecimento desta prática recomendada:** implementar um mecanismo de análise da causa raiz (RCA) para incidentes de segurança e uma fonte de evidências para suas obrigações de governança, risco e conformidade. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Durante uma investigação de segurança ou outros casos de uso com base em seus requisitos, você precisa ser capaz de analisar os logs relevantes a fim de registrar e entender o escopo total e a linha do tempo do incidente. Os logs também são necessários para geração de alertas indicando que ocorreram determinadas ações de interesse. É essencial selecionar, ativar, armazenar e configurar mecanismos de consulta, recuperação e alertas. 

 **Etapas da implementação** 
+  **Selecione e ative fontes de logs.** Antes de uma investigação de segurança, você precisa capturar logs relevantes para reconstruir, de forma retroativa a atividade em uma Conta da AWS. Selecione e ative fontes de logs relevantes para suas workloads. 

   Os critérios de seleção de fonte de logs devem se basear nos casos de uso necessários à sua empresa. Estabeleça uma trilha para cada Conta da AWS utilizando o AWS CloudTrail ou uma trilha de AWS Organizations e configure um bucket do Amazon S3 para ela. 

   O AWS CloudTrail é um serviço de registro em log que rastreia chamadas de API feitas em uma Conta da AWS capturando a atividade do serviço da AWS. É ativado por padrão com uma retenção de 90 dias de eventos de gerenciamento que podem ser [recuperados por meio do histórico de eventos do CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) utilizando o Console de gerenciamento da AWS, a AWS CLI ou um AWS SDK. Para ter uma retenção maior e visibilidade dos eventos de dados, [crie uma trilha do CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) e associe-a a um bucket do Amazon S3 e opcionalmente com um grupo de logs do Amazon CloudWatch. Como alternativa, você pode criar um [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html), que retém logs do CloudTrail por até sete anos e oferece um recursos e consultas baseado em SQL 

   A AWS recomenda que os clientes que utilizam uma VPC ativem o tráfego de rede e os logs de DNS por meio dos [Logs de fluxo de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) e dos[logs de consultas doAmazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html), respectivamente, transmitindo-os a um bucket do Amazon S3 ou a um grupo de logs do CloudWatch. É possível criar um log de fluxo de VPC, uma sub-rede ou uma interface de rede. Para logs de fluxo de VPC, é possível ser seletivo em relação a como e onde usar os logs de fluxo para reduzir o custo. 

   Logs do AWS CloudTrail, Logs de fluxo de VPC e logs de consulta do Route 53 Resolver são as fontes básicas de registro em log para oferecer compatibilidade com investigações de segurança na AWS. Também é possível usar o [Amazon Security Lake](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html) para coletar, normalizar e armazenar esses dados de logs no formato do Apache Parquet e no Open Cybersecurity Schema Framework (OCSF), que estão prontos para consulta. O Security Lake também é compatível com outros logs da AWS e logs de fontes de terceiros. 

   Os serviços da AWS podem gerar logs não capturados pelas fontes de log básicas, como logs do Elastic Load Balancing, logs do AWS WAF, logs de gravador do AWS Config, descobertas do Amazon GuardDuty, logs de auditoria do Amazon Elastic Kubernetes Service (Amazon EKS) e logs de aplicações e do sistema de instâncias do Amazon EC2. Para ter uma lista completa de opções de registro em log e monitoramento, consulte [Apêndice A: Definições de recursos de nuvem: registro em log e eventos](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/logging-and-events.html) do [Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/detection.html). 
+  **Recursos de registro em log de pesquisa para cada serviço e aplicação da AWS:** cada serviço e aplicação da AWS oferecem opções armazenamento de logs, sendo cada um com seus próprios recursos de retenção e ciclo de vida. Os dois serviços de armazenamento de logs mais comuns são Amazon Simple Storage Service (Amazon S3) e Amazon CloudWatch. Para períodos de retenção longos, é recomendável utilizar o Amazon S3 para seus recursos de economia e ciclo de vida flexíveis. Se a opção de registro em log principal for logs do Amazon CloudWatch, como opção, você deve considerar o arquivamento de logs menos acessados no Amazon S3. 
+  **Selecione o armazenamento de logs:** a escolha do armazenamento de logs, geralmente, é relacionada a qual ferramenta de consultas você utiliza, recursos de retenção, familiaridade e custo. As principais opções para armazenamento de logs são um bucket do Amazon S3 ou um grupo de logs do CloudWatch. 

   Um bucket do Amazon S3 oferece armazenamento econômico e durável com uma política de ciclo de vida opcional. Os logs armazenados em buckets do Amazon S3 podem ser consultados com serviços como o Amazon Athena. 

   Um grupo de logs do CloudWatch oferece armazenamento durável e um recurso de consultas incorporado por meio do CloudWatch Logs Insights. 
+  **Identifique a retenção de logs apropriada:** quando você utiliza um bucket do Amazon S3 ou o grupo de logs do CloudWatch para armazenar logs, é necessário estabelecer ciclos de vida adequados para cada fonte de logs a fim de otimizar os custos de armazenamento e recuperação. Os clientes geralmente têm entre três meses a um ano de logs prontamente disponíveis para consultas, com retenção de até sete anos. A escolha de disponibilidade e retenção deve se alinhar aos seus requisitos de segurança e um composto de atribuições regulatórias, estatutárias e de negócios. 
+  **Ative o registro em log para cada serviço e aplicação da AWS com políticas adequadas de retenção e ciclo de vida:** para cada serviço ou aplicação da AWS em sua organização, procure as orientações específicas de configuração de registro em log: 
  + [ Configurar a trilha do AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
  + [ Configurar logs de fluxo de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
  + [ Configurar as exportações de descobertas do Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_exportfindings.html)
  + [ Configurar os registros do AWS Config](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-config.html)
  + [ Configurar o tráfego de ACL da web do AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html)
  + [ Configurar os logs de tráfego de rede do AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-logging.html)
  + [ Configurar logs de acesso do Elastic Load Balancing ](https://docs.aws.amazon.com/)
  + [ Configurar logs de consulta do Amazon Route 53 resolver ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html)
  + [ Configurar logs do Amazon RDS ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.html)
  + [ Configurar logs do ambiente de gerenciamento Amazon EKS ](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
  + [ Configurar o agente do Amazon CloudWatch para instâncias do Amazon EC2 e servidores on-premises ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+  **Selecione e implemente os mecanismos de consulta para logs:** para consultas de log, você pode usar o [CloudWatch Logs Insight](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)s para dados armazenados em grupos de logs do CloudWatch, e o [Amazon Athena](https://aws.amazon.com/athena/) e o [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) para dados armazenados no Amazon S3. Também é possível usar ferramentas de consulta de terceiros, como um serviço de gerenciamento de eventos e informações de segurança (SIEM). 

   O processo para selecionar uma ferramenta de consulta de log deve considerar as pessoas, o processo e os aspectos de tecnologia de suas operações de segurança. Selecione uma ferramenta que atenda aos requisitos operacionais, de negócios e segurança, esteja acessível e possa receber manutenção no longo prazo. Lembre-se de que as ferramentas de consulta de logs funcionam da forma ideal quando o número de logs a serem verificados é mantido dentro dos limites da ferramenta. Não é incomum ter várias ferramentas de consulta devido a restrições financeiras ou técnicas. 

   Por exemplo, você pode usar uma ferramenta de gerenciamento de eventos e informações de segurança (SIEM) de terceiros para realizar consultas para os últimos 90 dias de dados, mas usar o Athena para realizar consultas além de 90 dias devido ao custo de ingestão de logs de um SIEM. Seja qual for a implementação, garanta que sua abordagem minimize o número de ferramentas necessárias para maximizar a eficiência operacional, especialmente durante a investigação de um evento de segurança. 
+  **Use logs para alertas:** a AWS oferece alertas por meio de vários serviços de segurança: 
  +  O [AWS Config](https://aws.amazon.com/config/) monitora e registra as configurações de recursos da AWS e permite automatizar as tarefas de avaliação e correção em relação às configurações desejadas. 
  +  O [Amazon GuardDuty](https://aws.amazon.com/guardduty/) é um serviço de detecção de ameaças que monitora de forma contínua a existência de atividade mal-intencionada e comportamento não autorizado para proteger suas Contas da AWS e workloads. O GuardDuty ingere, agrega e analisa informações de fontes, como eventos de dados e gerenciamento do AWS CloudTrail, logs de DNS, logs de fluxo de VPC e logs do Amazon EKS Audit. O GuardDuty extrai fluxos de dados independentes diretamente do CloudTrail, de logs de fluxo de VPC, logs de consulta ao DNS e do Amazon EKS. Não é necessário gerenciar políticas de bucket do Amazon S3 nem modificar a forma de coletar e armazenar logs. Ainda é recomendável reter esses logs para sua própria investigação e fins de conformidade. 
  +  O [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) fornece um único local que agrega, organiza e prioriza alertas de segurança ou descobertas de vários serviços da AWS e produtos opcionais de terceiros para oferecer uma visão abrangente dos alertas de segurança e do status de conformidade. 

   Você também pode utilizar mecanismos de geração de alertas personalizados para alertas de segurança não cobertos por esses serviços ou para alertas específicos relevantes para o seu ambiente. Para ter informações sobre a criação desses alertas e detecções, consulte [Detecção no Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/detection.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC04-BP02 Analisar logs, descobertas e métricas de forma centralizada](sec_detect_investigate_events_analyze_all.md) 
+  [SEC07-BP04 Definir o gerenciamento do ciclo de vida de dados](sec_data_classification_lifecycle_management.md) 
+  [SEC10-BP06 Pré-implantação de ferramentas](sec_incident_response_pre_deploy_tools.md) 

 **Documentos relacionados:** 
+ [ Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
+ [ Conceitos básicos do Amazon Security Lake ](https://aws.amazon.com/security-lake/getting-started/)
+ [ Conceitos básicos: Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)
+  [Soluções de segurança parceiros: registro em log e monitoramento](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 

 **Vídeos relacionados:** 
+ [AWS re:Invent 2022: Introdução ao Amazon Security Lake ](https://www.youtube.com/watch?v=V7XwbPPjXSY)

 **Exemplos relacionados:** 
+ [ Assisted Log Enabler for AWS](https://github.com/awslabs/assisted-log-enabler-for-aws/)
+ [ Exportação histórica de descobertas do AWS Security Hub CSPM](https://github.com/aws-samples/aws-security-hub-findings-historical-export)

 **Ferramentas relacionadas:** 
+ [ Snowflake for Cybersecurity ](https://www.snowflake.com/en/data-cloud/workloads/cybersecurity/)

# SEC04-BP02 Analisar logs, descobertas e métricas de forma centralizada
<a name="sec_detect_investigate_events_analyze_all"></a>

 as equipes de operações de segurança confiam na coleta de logs e no uso de ferramentas de pesquisa para descobrir possíveis eventos de interesse, que podem indicar atividade não autorizada ou alteração não intencional. No entanto, a simples análise de dados coletados e o processamento manual de informações são insuficientes para acompanhar o volume de informações provenientes de arquiteturas complexas. Somente a análise e os relatórios não facilitam a atribuição dos recursos certos para trabalhar um evento em tempo hábil. 

Uma prática recomendada para montar uma equipe madura de operações de segurança é integrar profundamente o fluxo de eventos e descobertas de segurança em um sistema de notificação e fluxo de trabalho, como um sistema de emissão de tíquetes, um sistema de erros ou problemas, ou outro sistema de gerenciamento de informações e eventos de segurança (SIEM). Isso remove o fluxo de trabalho de e-mails e relatórios estáticos, o que permite rotear, escalar e gerenciar eventos ou descobertas. Muitas organizações também estão integrando alertas de segurança em suas plataformas de bate-papo ou colaboração e de produtividade do desenvolvedor. Para organizações que estão iniciando com automações, um sistema de emissão de tíquetes orientado por APIs e de baixa latência oferece flexibilidade considerável para o planejamento de o que automatizar primeiro.

Essa prática recomendada aplica-se não só a eventos de segurança gerados a partir de mensagens de log que representam atividades do usuário ou eventos de rede, como também a alterações detectadas na própria infraestrutura. A capacidade de detectar alterações, determinar se uma alteração foi apropriada e, em seguida, rotear essas informações para o fluxo de trabalho de correção correto é essencial para manter e validar uma arquitetura segura, no contexto de alterações em que a natureza de sua indesejabilidade é suficientemente sutil para que sua execução não possa ser impedida com uma combinação de configuração do AWS Identity and Access Management(IAM) e do AWS Organizations.

O Amazon GuardDuty e o AWS Security Hub CSPM fornecem mecanismos de agregação, desduplicação e análise para registros de log que também são disponibilizados a você por meio de outros serviços da AWS. O GuardDuty ingere, agrega e analisa informações de fontes como gerenciamento e eventos de dados do AWS CloudTrail, logs de DNS de VPC e logs de fluxo de VPC. O Security Hub CSPM pode ingerir, agregar e analisar a saída do GuardDuty AWS Config, do Amazon Inspector, Amazon Macie, do AWS Firewall Manager e de um número significativo de produtos de segurança de terceiros disponíveis no AWS Marketplace e, se criado adequadamente, no seu próprio código. Tanto o GuardDuty quanto o Security Hub CSPM têm um modelo de membro administrador que pode agregar descobertas e insights em várias contas. O Security Hub CSPM geralmente é usado por clientes que têm um SIEM on-premises como um log do lado da AWS e um pré-processador e agregador de logs e alertas nos quais eles podem consumir o Amazon EventBridge por meio de um processador e encaminhador com base no AWS Lambda.

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Avaliar os recursos de processamento de log: avalie as opções disponíveis para o processamento de logs. 
  +  [Use Amazon OpenSearch Service to log and monitor (almost) everything (Usar o Amazon OpenSearch Service para registrar e monitorar (quase) tudo) ](https://d1.awsstatic.com/whitepapers/whitepaper-use-amazon-elasticsearch-to-log-and-monitor-almost-everything.pdf)
  +  [Encontre um parceiro especializado em soluções de registro e monitoramento ](https://aws.amazon.com/security/partner-solutions/#Logging_and_Monitoring)
+  Para começar a analisar logs do CloudTrail, experimente o Amazon Athena. 
  + [ Como configurar o Athena para analisar logs do CloudTrail ](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html)
+  Implementar o login centralizado na AWS: consulte a solução de exemplo da AWS a seguir para centralizar o log de várias fontes. 
  +  [Centralizar a solução de registro em log ](https://aws.amazon.com/solutions/centralized-logging/https://aws.amazon.com/solutions/centralized-logging/)
+  Implementar o registro em log centralizado com o parceiro: os parceiros da APN têm soluções para ajudar você a analisar os logs de forma centralizada. 
  + [ Registro em log e monitoramento ](https://aws.amazon.com/security/partner-solutions/#Logging_and_Monitoring)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Answers: registro em log centralizado ](https://aws.amazon.com/answers/logging/centralized-logging/)
+  [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+  [Amazon EventBridge ](https://aws.amazon.com/eventbridge)
+ [ Conceitos básicos: Amazon CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)
+  [Soluções de segurança parceiros: registro em log e monitoramento](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 

 **Vídeos relacionados:** 
+ [ Centrally Monitoring Resource Configuration and Compliance (Monitoramento centralizado de configuração e conformidade de recursos) ](https://youtu.be/kErRv4YB_T4)
+  [Remediating Amazon GuardDuty and AWS Security Hub CSPM Findings (Correção do Amazon GuardDuty e descobertas do AWS Security Hub) ](https://youtu.be/nyh4imv8zuk)
+ [ Threat management in the cloud: Amazon GuardDuty and AWS Security Hub CSPM (Gerenciamento de ameaças na nuvem: Amazon GuardDuty e AWS Security Hub) ](https://youtu.be/vhYsm5gq9jE)

# SEC04-BP03 Automatizar a resposta a eventos
<a name="sec_detect_investigate_events_auto_response"></a>

 O uso de automação para investigar e corrigir eventos reduz o esforço humano e erros e permite escalar recursos de investigação. Análises regulares ajudarão você a ajustar ferramentas de automação e iterar continuamente. 

Na AWS, a investigação de eventos de interesse e informações sobre alterações potencialmente inesperadas em um fluxo de trabalho automatizado pode ser obtida com o Amazon EventBridge. Esse serviço fornece um mecanismo de regras escalável, projetado para processar formatos de eventos da AWS nativos (como eventos do AWS CloudTrail) e personalizados, que você pode gerar com base em sua aplicação. O Amazon GuardDuty também permite rotear eventos em um sistema de fluxo de trabalho para usuários que criam sistemas de resposta a incidentes (AWS Step Functions), uma conta de segurança central ou um bucket para análise posterior.

A detecção de alterações e o roteamento dessas informações para o fluxo de trabalho correto podem ser realizados com o uso do Regras do AWS Config e [de pacotes de conformidade](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html). O AWS Config detecta alterações nos serviços em escopo (embora com maior latência do que o EventBridge) e gera eventos que podem ser analisados usando o Regras do AWS Config para reversão, aplicação da política de conformidade e encaminhamento de informações aos sistemas, como plataformas de gerenciamento de alterações e sistemas operacionais de emissão de tíquetes. Além de escrever suas próprias funções do Lambda para responder a eventos do AWS Config, você também pode aproveitar o [kit de desenvolvimento do Regras do AWS Config](https://github.com/awslabs/aws-config-rdk)e uma [biblioteca de código aberto](https://github.com/awslabs/aws-config-rules) do Regras do AWS Config. Os pacotes de conformidade são uma coleção de ações de correção e do Regras do AWS Config que você implanta como uma única entidade criada como um modelo YAML. O [modelo de pacote de conformidade de amostra](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-wa-Security-Pillar.html) está disponível no pilar Segurança do Well-Architected.

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Implementar alertas automatizados com o GuardDuty: o GuardDuty é um serviço de detecção de ameaças que monitora continuamente atividades mal-intencionadas e comportamentos não autorizados para proteger suas workloads e Contas da AWS. Habilite o GuardDuty e configure alertas automatizados. 
+  Automatizar o processo de investigação: desenvolva processos automatizados que investigam um evento e relatam informações a um administrador para economizar tempo. 
  + [ Laboratório: Amazon GuardDuty na prática ](https://hands-on-guardduty.awssecworkshops.com/)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Answers: registro em log centralizado ](https://aws.amazon.com/answers/logging/centralized-logging/)
+  [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+  [Amazon EventBridge ](https://aws.amazon.com/eventbridge)
+ [ Conceitos básicos: Amazon CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)
+  [Soluções de segurança parceiros: registro em log e monitoramento](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 
+ [ Como configurar o Amazon GuardDuty ](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html)

 **Vídeos relacionados:** 
+ [ Centrally Monitoring Resource Configuration and Compliance (Monitoramento centralizado de configuração e conformidade de recursos) ](https://youtu.be/kErRv4YB_T4)
+  [Remediating Amazon GuardDuty and AWS Security Hub CSPM Findings (Correção do Amazon GuardDuty e descobertas do AWS Security Hub) ](https://youtu.be/nyh4imv8zuk)
+ [ Threat management in the cloud: Amazon GuardDuty and AWS Security Hub CSPM (Gerenciamento de ameaças na nuvem: Amazon GuardDuty e AWS Security Hub) ](https://youtu.be/vhYsm5gq9jE)

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada de controles de detecção ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Detective_Controls/README.html)

# SEC04-BP04 Implementar eventos de segurança acionáveis
<a name="sec_detect_investigate_events_actionable_events"></a>

 Crie alertas para serem enviados à sua equipe para ação. Certifique-se de que os alertas incluam informações relevantes para a equipe agir. Para cada mecanismo de detecção existente, você também deve ter um processo, na forma de um [runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html) ou [playbook](https://wa.aws.amazon.com/wat.concept.playbook.en.html), para investigar. Por exemplo, quando você habilita o [Amazon GuardDuty](http://aws.amazon.com/guardduty), ele gera diferentes [descobertas](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings.html). Você deve ter uma entrada de runbook para cada tipo de descoberta, por exemplo, se um [cavalo de Troia](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_trojan.html) for descoberto, seu runbook terá instruções simples que instruem alguém a investigar e corrigir o problema. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Descubra as métricas disponíveis para serviços da AWS: descubra as métricas disponíveis por meio do Amazon CloudWatch para os serviços que você está usando. 
  +  [Documentação do serviço da AWS](https://aws.amazon.com/documentation/) 
  +  [Uso de métricas do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
+  Configure os alarmes do Amazon CloudWatch. 
  +  [Como usar os alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+  [Amazon EventBridge ](https://aws.amazon.com/eventbridge)
+  [Soluções de segurança parceiros: registro em log e monitoramento](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 

 **Vídeos relacionados:** 
+ [ Centrally Monitoring Resource Configuration and Compliance (Monitoramento centralizado de configuração e conformidade de recursos) ](https://youtu.be/kErRv4YB_T4)
+  [Remediating Amazon GuardDuty and AWS Security Hub CSPM Findings (Correção do Amazon GuardDuty e descobertas do AWS Security Hub) ](https://youtu.be/nyh4imv8zuk)
+ [ Threat management in the cloud: Amazon GuardDuty and AWS Security Hub CSPM (Gerenciamento de ameaças na nuvem: Amazon GuardDuty e AWS Security Hub) ](https://youtu.be/vhYsm5gq9jE)

# Proteção de infraestrutura
<a name="a-infrastructure-protection"></a>

**Topics**
+ [SEGURANÇA 5. Como proteger seus recursos de rede?](sec-05.md)
+ [SEGURANÇA 6. Como proteger seus recursos de computação?](sec-06.md)

# SEGURANÇA 5. Como proteger seus recursos de rede?
<a name="sec-05"></a>

Qualquer carga de trabalho que tenha alguma forma de conectividade de rede, seja a Internet ou uma rede privada, exige várias camadas de defesa para ajudar a proteger contra ameaças externas e internas baseadas em rede.

**Topics**
+ [SEC05-BP01 Criar camadas de rede](sec_network_protection_create_layers.md)
+ [SEC05-BP02 Controlar tráfego de todas as camadas](sec_network_protection_layered.md)
+ [SEC05-BP03 Automatizar a proteção da rede:](sec_network_protection_auto_protect.md)
+ [SEC05-BP04 Implementar inspeção e proteção](sec_network_protection_inspection.md)

# SEC05-BP01 Criar camadas de rede
<a name="sec_network_protection_create_layers"></a>

Agrupe os componentes que compartilham requisitos de confidencialidade em camadas para minimizar o possível escopo do impacto do acesso não autorizado. Por exemplo, um cluster de banco de dados em uma nuvem privada virtual (VPC) sem necessidade de acesso à Internet deve ser colocado em sub-redes sem nenhuma rota para/ou proveniente da Internet. O tráfego só deve fluir do próximo recurso menos sigiloso adjacente. Considere uma aplicação da web atrás de um balanceador de carga. Seu banco de dados não deve ser acessível diretamente do balanceador de carga. Somente a lógica de negócios ou o servidor da web tem acesso direto ao seu banco de dados. 

 **Resultado desejado:** criar uma rede em camadas. Redes em camadas ajudam a agrupar logicamente componentes de rede semelhantes. Elas também reduzem o possível escopo de impacto do acesso não autorizado à rede. Uma rede configurada adequadamente em camadas dificulta que usuários não autorizados adaptem recursos adicionais em seu ambiente da AWS. Além de garantir caminhos de rede internos, você também deve proteger sua borda de rede, como aplicações da web e endpoints de API. 

 **Antipadrões comuns:** 
+  Criar todos os recursos em uma única VPC ou sub-rede. 
+  Utilizar grupos de segurança excessivamente permissivos. 
+  Não utilizar sub-redes. 
+  Permitir o acesso direto aos armazenamentos de dados, como bancos de dados. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Os componentes como instâncias do Amazon Elastic Compute Cloud (Amazon EC2), clusters de banco de dados do Amazon Relational Database Service (Amazon RDS) e funções do AWS Lambda que compartilham requisitos de acessibilidade podem ser segmentados em camadas formadas por sub-redes. Considere implantar workloads sem servidor, como funções do [Lambda](https://docs.aws.amazon.com/lambda/index.html), em uma VPC ou atrás de um [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html). As tarefas do [AWS Fargate](https://aws.amazon.com/fargate/getting-started/) que não têm necessidade de acesso à Internet devem ser colocadas em sub-redes sem rota para ou proveniente da Internet. Essa abordagem em camadas reduz o impacto da configuração incorreta de uma única camada, o que pode permitir o acesso não intencional. Para o AWS Lambda, você pode executar as funções em sua VPC para utilizar os controles baseados em VPC. 

 Para a conectividade de rede que pode incluir milhares de VPCs, Contas da AWS e redes on-premises, você deve utilizar o [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/). O Transit Gateway age como um hub que controla como o tráfego é roteado entre todas as redes conectadas, que agem como raios. O tráfego entre o Amazon Virtual Private Cloud (Amazon VPC) e o Transit Gateway permanece na rede privada da AWS, o que reduz a exposição externa a usuários não autorizados e possíveis problemas de segurança. O emparelhamento entre regiões do Transit Gateway também criptografa o tráfego entre regiões sem nenhum ponto único de falha ou gargalo de largura de banda. 

 **Etapas da implementação** 
+  **Utilize o [Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html) para analisar o caminho entre uma origem e um destino com base na configuração:** o Reachability Analyzer permite a você automatizar a verificação da conectividade para e proveniente de recursos conectados à VPC. Observe que essa análise é realizada analisando a configuração (nenhum pacote de rede é enviado na realização da análise). 
+  **Utilize o [Analisador de Acesso à Rede Amazon VPC](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html) para identificar o acesso acidental à rede aos recursos:** o Analisador de Acesso à Rede Amazon VPC possibilita especificar seus requisitos de acesso à rede identificar possíveis caminhos de rede. 
+  **Considere se os recursos precisam estar em uma sub-rede pública:** não coloque os recursos em sub-redes públicas de sua VPC a menos que eles devam receber tráfego de rede de entrada de origens públicas. 
+  **Crie [sub-redes em suas VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html):** crie sub-redes para cada camada de rede (em grupos que incluam várias zonas de disponibilidade) para melhorar a microssegmentação. Verifique também se você associou as [tabelas de rotas](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html) corretas com suas sub-redes para controlar o roteamento e a conectividade de rede. 
+  **Utilize o [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/security-group-policies.html) para gerenciar seus grupos de segurança de VPC:** o AWS Firewall Manager ajuda a reduzir o trabalho de usar vários grupos de segurança. 
+  **Utilize o [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) para proteger contra vulnerabilidades comuns da web:** o AWS WAF pode ajudar a melhorar a segurança de borda inspecionando o tráfego quanto a vulnerabilidades comuns da web, como injeção de SQL. Ele também permite restringir o tráfego de endereços IP originários de determinados países ou locais geográficos. 
+  **Utilize o [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) como uma rede de distribuição de conteúdo (CDN):** o Amazon CloudFront pode ajudar a acelerar sua aplicação da web armazenando dados mais perto de seus usuários. Ele também pode melhorar a segurança de borda aplicando HTTPS, restringindo o acesso a áreas geográficas e garantindo que o tráfego de rede possa acessar somente recursos roteados por meio do CloudFront. 
+  **Utilize o [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) ao criar interfaces de programação de aplicações (APIs):** o Amazon API Gateway ajuda a publicar, monitorar e proteger APIs REST, HTTPS e de WebSocket. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html) 
+ [ Amazon Inspector ](https://aws.amazon.com/inspector)
+  [Segurança na Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html) 
+ [ Reachability Analyzer ](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
+ [ Analisador de Acesso à Rede Amazon VPC ](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/getting-started.html#run-analysis)

 **Vídeos relacionados:** 
+  [Arquiteturas de referência do AWS Transit Gateway para várias VPCs ](https://youtu.be/9Nikqn_02Oc)
+  [Aceleração e proteção de aplicações com o Amazon CloudFront, o AWS WAF e o AWS Shield](https://youtu.be/0xlwLEccRe0) 
+ [AWS re:Inforce 2022: Validar controles de acesso à rede eficazes na AWS](https://www.youtube.com/watch?v=aN2P2zeQek0)
+ [AWS re:Inforce 2022: Proteções avançadas contra bots usando o AWS WAF](https://www.youtube.com/watch?v=pZ2eftlwZns)

 **Exemplos relacionados:** 
+  [Well-Architected Lab: Implantação automatizada de VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 
+ [ Workshop: Analisador de Acesso à Rede Amazon VPC ](https://catalog.us-east-1.prod.workshops.aws/workshops/cf2ecaa4-e4be-4f40-b93f-e9fe3b1c1f64)

# SEC05-BP02 Controlar tráfego de todas as camadas
<a name="sec_network_protection_layered"></a>

  ao projetar sua topologia de rede, você deve examinar os requisitos de conectividade de cada componente. Por exemplo, se um componente precisa de acesso à Internet (entrada e saída), conectividade com VPCs, serviços de borda e datacenters externos. 

 Uma VPC permite que você defina a topologia de rede que abrange uma Região da AWS com um intervalo de endereços IPv4 privados que você define ou um intervalo de endereços IPv6 que a AWS seleciona. Você deve aplicar vários controles com uma abordagem detalhada de defesa para tráfego de entrada e saída, incluindo o uso de grupos de segurança (firewall de inspeção com estado), Network ACLs, sub-redes e tabelas de rotas. Você pode criar sub-redes em uma zona de disponibilidade dentro de uma VPC. Cada sub-rede tem uma tabela de rotas associada que define regras de roteamento para gerenciar os caminhos do tráfego dentro da sub-rede. Você pode definir uma sub-rede roteável na Internet com uma rota que siga até um gateway da Internet ou gateway NAT associado à VPC ou que passe por outra VPC. 

 Quando uma instância, um banco de dados do Amazon Relational Database Service(Amazon RDS) ou outro serviço é executado em uma VPC, ela tem seu próprio grupo de segurança por interface de rede. Esse firewall está fora da camada do sistema operacional e pode ser usado para definir regras para o tráfego permitido de entrada e saída. Você também pode definir relacionamentos entre grupos de segurança. Por exemplo, as instâncias em um grupo de segurança no nível do banco de dados aceitam somente o tráfego de instâncias no nível do aplicativo, por referência aos grupos de segurança aplicados às instâncias envolvidas. A menos que você esteja usando protocolos não baseados em TCP, não deve ser necessário ter uma instância do Amazon Elastic Compute Cloud(Amazon EC2) diretamente acessível pela Internet (mesmo com portas restritas por grupos de segurança) sem um balanceador de carga ou o [CloudFront](https://aws.amazon.com/cloudfront). Isso ajuda a protegê-lo contra acesso não intencional surgido por um problema de sistema operacional ou aplicativo. Uma sub-rede também pode ter uma Network ACL anexada a ela, que atua como um firewall sem estado. Você deve configurar a Network ACL para restringir a abrangência do tráfego permitido entre camadas. Observe que é preciso definir regras de entrada e de saída. 

 Alguns serviços da AWS requerem componentes para acessar a Internet para fazer chamadas de API, onde [os endpoints de API da AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html) estão localizados. Outros serviços da AWS usam [VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html) dentro das suas Amazon VPCs. Muitos serviços da AWS, incluindo o Amazon S3 e o Amazon DynamoDB, oferecem suporte a endpoints da VPC, e essa tecnologia foi generalizada no [AWS PrivateLink](https://aws.amazon.com/privatelink/). Recomendamos o uso dessa abordagem para acessar serviços da AWS, serviços de terceiros e seus próprios serviços hospedados em outras VPCs com segurança. Todo o tráfego de rede do AWS PrivateLink permanece no backbone global da AWS e nunca atravessa a Internet. A conectividade só pode ser iniciada pelo consumidor do serviço e não pelo provedor do serviço. O uso do AWS PrivateLink para acesso a serviços externos permite criar VPCs air-gapped sem acesso à Internet e ajuda a proteger suas VPCs de vetores de ameaças externas. Os serviços de terceiros podem usar o AWS PrivateLink para permitir que os clientes se conectem aos serviços de suas VPCs por meio de endereços IP privados. Para ativos da VPC que precisam estabelecer conexões de saída com a Internet, elas podem ser feitas somente de saída (unidirecional) por meio de um gateway NAT gerenciado pela AWS, de um gateway da Internet somente de saída ou de proxies de Web criados e gerenciados por você. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Controlar o tráfego de rede em uma VPC: implemente as práticas recomendadas de VPC para controlar o tráfego. 
  +  [Segurança da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html) 
  +  [VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) 
  +  [Grupo de segurança da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) 
  +  [ACLs de rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) 
+  Controlar o tráfego na borda: implemente serviços de borda, como o Amazon CloudFront, para fornecer uma camada adicional de proteção e outros recursos. 
  +  [Casos de uso do Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/IntroductionUseCases.html) 
  +  [AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
  +  [AWS Web Application Firewall (AWS WAF)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-section.html) 
  +  [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
  +  [Roteamento de entrada da Amazon VPC](https://aws.amazon.com/about-aws/whats-new/2019/12/amazon-vpc-ingress-routing-insert-virtual-appliances-forwarding-path-vpc-traffic/) 
+  Controlar o tráfego de rede privada: implemente serviços que protegem o tráfego privado da sua workload. 
  +  [Emparelhamento de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) 
  +  [Serviços de endpoint da Amazon VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) 
  +  [Amazon VPC Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
  +  [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) 
  +  [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) 
  +  [AWS Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/user-getting-started.html) 
  +  [Pontos de acesso do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/access-points.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) 
+  [Amazon Inspector](https://aws.amazon.com/inspector) 
+  [Conceitos básicos do AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) 

 **Vídeos relacionados:** 
+  [AWS Transit Gateway reference architectures for many VPCs (Arquiteturas de referência do AWS Transit Gateway para várias VPCs)](https://youtu.be/9Nikqn_02Oc) 
+  [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield (Aceleração e proteção de aplicações com o Amazon CloudFront, o AWS WAF e o AWS Shield) ](https://youtu.be/0xlwLEccRe0)

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada da VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 

# SEC05-BP03 Automatizar a proteção da rede:
<a name="sec_network_protection_auto_protect"></a>

 Automatize os mecanismos de proteção para fornecer uma rede de autodefesa com base em inteligência de ameaças e detecção de anomalias. Por exemplo, ferramentas de detecção e prevenção de intrusão que podem se adaptar às ameaças atuais e reduzir seu impacto. Um firewall de aplicação Web é um exemplo de onde você pode automatizar a proteção de rede; por exemplo, usando a solução AWS WAF Security Automations ([https://github.com/awslabs/aws-waf-security-automations](https://github.com/awslabs/aws-waf-security-automations)) para bloquear automaticamente solicitações originadas de endereços IP associados a agentes de ameaças conhecidos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Automatize a proteção para tráfego baseado na Web: a AWS oferece uma solução que usa o AWS CloudFormation para implantar automaticamente um conjunto de regras do AWS WAF projetadas para filtrar ataques comuns baseados na Web. Os usuários podem selecionar entre recursos de proteção pré-configurados que definem as regras incluídas em uma lista de controle de acesso da Web (ACL da Web) do AWS WAF. 
  +  [Automações de segurança do AWS WAF](https://aws.amazon.com/solutions/aws-waf-security-automations/) 
+  Considere as soluções de AWS Partner: os parceiros da AWS oferecem centenas de produtos líderes do setor que são equivalentes, idênticos ou se integram aos controles existentes nos seus ambientes on-premises. Esses produtos complementam os serviços da AWS já existentes para que os clientes possam implantar uma arquitetura de segurança abrangente e obter uma experiência mais uniforme na nuvem e no ambiente on-premises. 
  +  [Segurança da infraestrutura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) 
+  [Amazon Inspector](https://aws.amazon.com/inspector) 
+ [Segurança da Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html)
+  [Conceitos básicos do AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) 

 **Vídeos relacionados:** 
+  [AWS Transit Gateway reference architectures for many VPCs (Arquiteturas de referência do AWS Transit Gateway para várias VPCs)](https://youtu.be/9Nikqn_02Oc) 
+  [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield (Aceleração e proteção de aplicações com o Amazon CloudFront, o AWS WAF e o AWS Shield) ](https://youtu.be/0xlwLEccRe0)

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada da VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 

# SEC05-BP04 Implementar inspeção e proteção
<a name="sec_network_protection_inspection"></a>

 Inspecione e filtre o tráfego em cada camada. É possível inspecionar suas configurações de VPC quanto a possíveis acessos não intencionais usando o [VPC Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html). Especifique seus requisitos de acesso à rede e identifique possíveis caminhos de rede que não os atendem. Para componentes que fazem transações por meio de protocolos baseados em HTTP, um firewall de aplicativo Web pode ajudar a proteger contra ataques comuns. [AWS WAF](https://aws.amazon.com/waf) é um firewall para aplicativos web que permite monitorar e bloquear solicitações HTTP(s) que correspondem às regras configuráveis que são encaminhadas para uma API do Amazon API Gateway, o Amazon CloudFront ou um Application Load Balancer. Para começar a usar o AWS WAF, você pode usar o [AWS Managed Rules](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group) em combinação com as suas próprias ou usar [integrações de parceiros existentes](https://aws.amazon.com/waf/partners/). 

 Para gerenciar o AWS WAF, proteções do AWS Shield Advanced e grupos de segurança do Amazon VPC no AWS Organizations, você pode usar o AWS Firewall Manager. Ele permite configurar e gerenciar centralmente regras de firewall entre contas e aplicativos, simplificando a imposição de regras comuns em escala. Ele também permite que você responda rapidamente a ataques, usando o [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-responding.html)ou [soluções](https://aws.amazon.com/solutions/aws-waf-security-automations/) capazes de bloquear automaticamente solicitações indesejadas para suas aplicações Web. O Firewall Manager também funciona com o [AWS Network Firewall](https://aws.amazon.com/network-firewall/). O AWS Network Firewall é um serviço gerenciado que usa um mecanismo de regras para fornecer controle refinado sobre o tráfego de rede com e sem estado. Ele oferece suporte às especificações do sistema de prevenção de intrusões (IPS) de código aberto [compatível com Suricata ](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html) para regras para ajudar a proteger sua workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Configure o Amazon GuardDuty: o GuardDuty é um serviço de detecção de ameaças que monitora continuamente atividades mal-intencionadas e comportamentos não autorizados para proteger suas workloads e Contas da AWS. Habilite o GuardDuty e configure alertas automatizados. 
  +  [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) 
  +  [Laboratório: Implantação automatizada de controles de detecção](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Detective_Controls/README.html) 
+  Configure os logs de fluxo da nuvem privada virtual (VPC): os logs de fluxo da VPC é um recurso que permite capturar informações sobre o tráfego de IP direcionado e proveniente de interfaces de rede na sua VPC. Os dados de log de fluxo podem ser publicados no Amazon CloudWatch Logs e no Amazon Simple Storage Service (Amazon S3). Depois de criar um log de fluxo, você pode recuperar e visualizar seus dados no destino escolhido. 
+  Considere o espelhamento de tráfego da VPC: o espelhamento de tráfego é um recurso da Amazon VPC que pode ser usado para copiar o tráfego de rede de uma interface de rede elástica de instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e enviá-lo para dispositivos de segurança e monitoramento fora de banda para inspeção de conteúdo, monitoramento de ameaças e solução de problemas. 
  +  [Espelhamento de tráfego de VPC](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) 
+  [Amazon Inspector](https://aws.amazon.com/inspector) 
+  [Segurança da Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html) 
+  [Conceitos básicos do AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) 

 **Vídeos relacionados:** 
+  [AWS Transit Gateway reference architectures for many VPCs (Arquiteturas de referência do AWS Transit Gateway para várias VPCs)](https://youtu.be/9Nikqn_02Oc) 
+  [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield (Aceleração e proteção de aplicações com o Amazon CloudFront, o AWS WAF e o AWS Shield)](https://youtu.be/0xlwLEccRe0) 

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada da VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 

# SEGURANÇA 6. Como proteger seus recursos de computação?
<a name="sec-06"></a>

Os recursos de computação exigem várias camadas de defesa para ajudar na proteção contra ameaças externas e internas. Recursos de computação incluem instâncias do EC2, contêineres, funções do AWS Lambda, serviços de banco de dados, dispositivos de IoT e muito mais.

**Topics**
+ [SEC06-BP01 Fazer o gerenciamento de vulnerabilidades](sec_protect_compute_vulnerability_management.md)
+ [SEC06-BP02 Reduzir a superfície de ataque](sec_protect_compute_reduce_surface.md)
+ [SEC06-BP03 Implementar serviços gerenciados](sec_protect_compute_implement_managed_services.md)
+ [SEC06-BP04 Automatizar a proteção da computação](sec_protect_compute_auto_protection.md)
+ [SEC06-BP05 Permitir que as pessoas executem ações a uma distância](sec_protect_compute_actions_distance.md)
+ [SEC06-BP06 Validar a integridade do software](sec_protect_compute_validate_software_integrity.md)

# SEC06-BP01 Fazer o gerenciamento de vulnerabilidades
<a name="sec_protect_compute_vulnerability_management"></a>

Verifique e corrija com frequência vulnerabilidades no código, nas dependências e na infraestrutura para proteger-se contra novas ameaças.

 **Resultado desejado:** criar e manter um programa de gerenciamento de vulnerabilidade. Verificar regularmente e corrigir recursos, como instâncias do Amazon EC2, contêineres do Amazon Elastic Container Service (Amazon ECS) e workloads do Amazon Elastic Kubernetes Service (Amazon EKS). Configurar janelas de manutenção para recursos gerenciados da AWS, como bancos de dados Amazon Relational Database Service (Amazon RDS). Utilizar a verificação de código estático para inspecionar a existência de problemas comuns no código-fonte da aplicação. Considerar testes de penetração de aplicações da web se sua organização tiver as habilidades obrigatórias ou puder contratar assistência externa. 

 **Antipadrões comuns:** 
+  Não ter um programa de gerenciamento de vulnerabilidades. 
+  Realizar aplicação de patches do sistema sem considerar a gravidade ou como evitar riscos. 
+  Utilizar software que ultrapassou a data de fim de vida útil (EOL) indicada pelo fornecedor. 
+  Implantar código em produção antes de analisar a existência de problemas de segurança. 

 **Benefícios do estabelecimento desta prática recomendada:** 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Um programa de gerenciamento de vulnerabilidades inclui avaliação de segurança, identificação de problemas, priorização e realização de operações de patch como parte da solução dos problemas. A automação é a chave para verificar de forma contínua as workloads quanto a problemas e exposição acidental à rede e realização de remediação. Automatizar a criação e atualizar os recursos economiza tempo e reduz o risco de erros de configuração que criam mais problemas. Um programa de gerenciamento de vulnerabilidades bem projetado também deve considerar testes de vulnerabilidades durante o desenvolvimento e os estágios de implantação do ciclo de vida do software. Implementar o gerenciamento de vulnerabilidades durante o desenvolvimento e a implantação ajuda a reduzir a chance de uma vulnerabilidade atingir seu ambiente de produção. 

 Implementar um programa de gerenciamento de vulnerabilidades exige um bom entendimento do [Modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) e como ele se relaciona com suas workloads específicas. Segundo o modelo de responsabilidade compartilhada, a AWS é responsável por proteger a infraestrutura da Nuvem AWS. Essa infraestrutura abrange o hardware, o software, as redes e as instalações que executam os serviços da Nuvem AWS. Você é responsável pela segurança na nuvem, por exemplo, os dados reais, a configuração de segurança e as tarefas de gerenciamento de instâncias do Amazon EC2 e por garantir que seus objetos do Amazon S3 sejam classificados e configurados corretamente. Sua abordagem ao gerenciamento de vulnerabilidades também pode variar dependendo dos serviços consumidos. Por exemplo, a AWS gerencia a aplicação de patches para nosso serviço de banco de dados relacional gerenciado, o Amazon RDS, mas você seria responsável pela colocação de patches em bancos de dados auto-hospedados. 

 A AWS tem uma série de serviços para ajudar com seu programa de gerenciamento de vulnerabilidades. O [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) verifica de forma contínua as workloads da AWS quanto a problemas de software e acesso acidental à rede. [O AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) ajuda a gerenciar a aplicação de patches em suas instâncias do Amazon EC2. O Amazon Inspector e o Systems Manager podem ser visualizados no [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html), um serviço de gerenciamento de procedimentos de segurança na nuvem que ajuda a automatizar verificações de segurança da AWS e centralizar alertas de segurança. 

 O [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) pode ajudar a identificar possíveis problemas em aplicações Java e Python utilizando análise de código estático. 

 **Etapas da implementação** 
+  **Configurar o [Amazon Inspector](https://docs.aws.amazon.com/inspector/v1/userguide/inspector_introduction.html):** o Amazon Inspector detecta automaticamente instâncias do Amazon EC2 recém-executadas, funções do Lambda e imagens de contêiner elegíveis enviadas ao Amazon ECR e as verifica imediatamente quanto a problemas de software, possíveis defeitos e exposição acidental à rede. 
+  **Verificar o código-fonte:** verifique as bibliotecas e as dependências quanto a problemas e defeitos. O [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) pode verificar e fornecer recomendações para corrigir [problemas de segurança comuns](https://docs.aws.amazon.com/codeguru/detector-library/index.html) para aplicações Java e Python. [A OWASP Foundation](https://owasp.org/www-community/Source_Code_Analysis_Tools) publica uma lista de ferramentas de análise de código-fonte (também conhecidas como ferramentas SAST). 
+  **Implementar um mecanismo para verificar e aplicar patches ao seu ambiente existente, bem como verificação como parte de um processo de construção de pipeline de CI/CD:** implemente um mecanismo para verificar e aplicar patches quanto a problemas em suas dependências e sistemas operacionais a fim de ajudar a proteger-se contra novas ameaças. Execute esse mecanismo regularmente. O gerenciamento de vulnerabilidade de software é essencial ao entendimento de onde é necessário aplicar patches ou resolver problemas de software. Priorize a remediação de possíveis problemas de segurança incorporando avaliações de vulnerabilidade no início de seu pipeline de integração/entrega contínua (CI/CD). Sua abordagem pode variar com base nos serviços da AWS que você está consumindo. Para conferir a existência de possíveis problemas no software em execução em instâncias do Amazon EC2, adicione o [Amazon Inspector](https://aws.amazon.com/inspector/) ao seu pipeline para alertar e interromper o processo de compilação se forem detectados problemas ou possíveis defeitos. O Amazon Inspector monitora recursos de forma contínua. Você também pode utilizar produtos de código aberto, como [OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/), [Snyk](https://snyk.io/product/open-source-security-management/), [OpenVAS](https://www.openvas.org/), gerenciadores de pacotes e ferramentas de AWS Partner para gerenciamento de vulnerabilidades. 
+  **Utilize o [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html):** você é responsável pelo gerenciamento de patches para seus recursos do AWS, incluindo instâncias do Amazon Elastic Compute Cloud (Amazon EC2), imagens de máquina da Amazon (AMIs) e outros recursos de computação. O [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) automatiza o processo de aplicação de patches em instâncias gerenciadas com atualizações relacionadas à segurança e outros tipos de atualizações. O Patch Manager pode ser utilizado para aplicar patches em instâncias do Amazon EC2 para sistemas operacionais e aplicações, como aplicações da Microsoft, pacotes de serviços Windows e atualizações de versão secundária para instâncias baseadas em Linux. Além do Amazon EC2, o Patch Manager também pode ser utilizado para aplicar patches em servidores on-premises. 

   Para ter uma lista de sistemas operacionais compatíveis, consulte [Sistemas operacionais compatíveis](https://docs.aws.amazon.com/systems-manager/latest/userguide/prereqs-operating-systems.html) no Guia do usuário do Systems Manager. Você pode verificar instâncias para ver apenas um relatório de patches ausentes ou verificar e instalar automaticamente todos os patches ausentes. 
+  **Utilize do [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html):** o Security Hub CSPM oferece uma visão abrangente do estado de seu sistema na AWS. Ele coleta dados de segurança em [vários serviços da AWS](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-internal-providers.html) e oferece essas descobertas em um formato personalizado, possibilitando priorizar as descobertas de segurança em serviços da AWS. 
+  **Utilize o [AWS CloudFormation](https://aws.amazon.com/cloudformation/):** o [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) é um serviço de infraestrutura como código (IaC) que pode ajudar com o gerenciamento de vulnerabilidades automatizando a implantação de recursos e padronizando a arquitetura de recursos em várias contas e ambientes. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Visão geral de segurança do AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS--Security.pdf) 
+ [ Amazon CodeGuru ](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Gerenciamento aprimorado e automatizado de vulnerabilidades para workloads de nuvem com um novo Amazon Inspector ](https://aws.amazon.com/blogs/aws/improved-automated-vulnerability-management-for-cloud-workloads-with-a-new-amazon-inspector/)
+ [ Automatizar o gerenciamento e a remediação de vulnerabilidades na AWS usando o Amazon Inspector e o AWS Systems Manager: Parte 1 ](https://aws.amazon.com/blogs/mt/automate-vulnerability-management-and-remediation-in-aws-using-amazon-inspector-and-aws-systems-manager-part-1/)

 **Vídeos relacionados:** 
+  [Proteção de serviços com tecnologia sem servidor e de contêiner](https://youtu.be/kmSdyN9qiXY) 
+  [Práticas recomendadas de segurança para o serviço de metadados de instância do Amazon EC2](https://youtu.be/2B5bhZzayjI) 

# SEC06-BP02 Reduzir a superfície de ataque
<a name="sec_protect_compute_reduce_surface"></a>

 Reduza a exposição ao acesso não intencional protegendo os sistemas operacionais e minimizando componentes, bibliotecas e serviços consumíveis externamente em uso. Primeiro, diminua o número de componentes não utilizados, sejam eles pacotes de sistema operacional ou aplicações para workloads baseadas no Amazon Elastic Compute Cloud (Amazon EC2), sejam eles módulos de software externos no código, para todas as workloads. Encontre muitos guias de configuração de proteção e segurança para sistemas operacionais comuns e software de servidor. Por exemplo, você pode começar com o [Center for Internet Security](https://www.cisecurity.org/) e iterar.

 No Amazon EC2, e possível criar as próprias imagens de máquina da Amazon (AMIs), corrigidas e reforçadas, para ajudar você a atender aos requisitos de segurança específicos da sua organização. Os patches e outros controles de segurança aplicados na AMI são efetivos no momento em que foram criados. Eles não são dinâmicos, a menos que você modifique após a inicialização, por exemplo, com o AWS Systems Manager. 

 É possível simplificar o processo de criação de AMIs seguras com o EC2 Image Builder. O EC2 Image Builder reduz significativamente o esforço necessário para criar e manter imagens douradas sem escrever e manter a automação. Quando as atualizações de software ficam disponíveis, o Image Builder produz automaticamente uma nova imagem sem exigir que os usuários iniciem manualmente as compilações de imagem. O EC2 Image Builder permite validar facilmente a funcionalidade e a segurança de suas imagens antes de usá-las na produção com testes fornecidos pela AWS e seus próprios testes. Também é possível aplicar as configurações de segurança fornecidas pela AWS para proteger ainda mais suas imagens para atender aos critérios de segurança internos. Por exemplo, você pode produzir imagens em conformidade com o padrão do Guia de implementação técnica de segurança (STIG) usando modelos fornecidos pela AWS. 

 Com ferramentas de análise de código estático de terceiros é possível identificar problemas de segurança comuns, como limites de entrada de função não verificados, bem como vulnerabilidades e exposições comuns (CVEs) aplicáveis. Você pode usar o [Amazon CodeGuru](https://aws.amazon.com/codeguru/) para os idiomas compatíveis. As ferramentas de verificação de dependência também podem ser usadas para determinar se as bibliotecas com as quais o código está vinculado são as versões mais recentes, estão livres de CVEs e têm condições de licenciamento que atendem aos requisitos da política de software. 

 Usando o Amazon Inspector, você pode executar avaliações de configuração de CVEs conhecidas em suas instâncias, avaliar parâmetros de segurança e automatizar a notificação de defeitos. O Amazon Inspector é executado em instâncias de produção ou em um pipeline de compilação e notifica desenvolvedores e engenheiros quando descobertas estão presentes. Você pode acessar as descobertas programaticamente e direcionar sua equipe para os registros em atraso e os sistemas de rastreamento de bugs. [EC2 Image Builder](https://aws.amazon.com/image-builder/) pode ser usado para manter imagens de servidor (AMIs) com aplicação automática de patches, aplicação de políticas de segurança fornecidas pela AWS e outras personalizações. Ao usar contêineres, implemente a [Verificação de imagens do ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html) no pipeline de compilação e regularmente no repositório de imagens para procurar CVEs nos contêineres. 

 Embora o Amazon Inspector e outras ferramentas sejam eficazes na identificação de configurações e CVEs presentes, outros métodos são necessários para testar a carga de trabalho no nível do aplicativo. [Fuzzing](https://owasp.org/www-community/Fuzzing) é um método conhecido de encontrar erros usando automação para injetar dados malformados em campos de entrada e outras áreas do aplicativo. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Configure os sistemas operacionais: configure os sistemas operacionais para atender às práticas recomendadas. 
  +  [Securing Amazon Linux](https://www.cisecurity.org/benchmark/amazon_linux/) 
  +  [Securing Microsoft Windows Server](https://www.cisecurity.org/benchmark/microsoft_windows_server/) 
+  Configure recursos em contêiner para atender às práticas recomendadas de segurança. 
+  Implemente as práticas recomendadas do AWS Lambda. 
  +  [Práticas recomendadas do AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Replacing a Bastion Host with Amazon EC2 Systems Manager (Como substituir um host traga a sua própria licença pelo Amazon EC2 Systems Manager)](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Security Overview of AWS Lambda (Visão geral de segurança do AWS Lambda)](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Vídeos relacionados:** 
+  [Running high-security workloads on Amazon EKS (Execução de workloads de alta segurança no Amazon EKS)](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services (Proteção de serviços com tecnologia sem servidor e de contêiner)](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service (Práticas recomendadas de segurança para o serviço de metadados de instância do Amazon EC2](https://youtu.be/2B5bhZzayjI) 

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada do firewall de aplicações Web](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 

# SEC06-BP03 Implementar serviços gerenciados
<a name="sec_protect_compute_implement_managed_services"></a>

 Implemente serviços que gerenciam recursos, como o Amazon Relational Database Service (Amazon RDS), o AWS Lambda e o Amazon Elastic Container Service (Amazon ECS), para reduzir as tarefas de manutenção de segurança como parte do modelo de responsabilidade compartilhada. Por exemplo, o Amazon RDS ajuda você a configurar, operar e escalar um banco de dados relacional, automatiza tarefas de administração, como provisionamento de hardware, configuração de banco de dados, aplicação de patches e backups. Isso significa que você tem mais tempo livre para se concentrar na proteção da aplicação de outras maneiras descritas no AWS Well-Architected Framework. O Lambda permite executar código sem provisionar nem gerenciar servidores e, portanto, você só precisa se concentrar na conectividade, na invocação e na segurança em nível de código, e não na infraestrutura ou no sistema operacional. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Explorar os serviços disponíveis: explore, teste e implemente serviços que gerenciam recursos, como Amazon RDS, AWS Lambda e Amazon ECS. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Site da AWS](https://aws.amazon.com/)
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Replacing a Bastion Host with Amazon EC2 Systems Manager (Como substituir um bastion host com o Amazon EC2 Systems Manager)](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Security Overview of AWS Lambda (Visão geral de segurança do AWS Lambda)](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Vídeos relacionados:** 
+  [Running high-security workloads on Amazon EKS (Execução de workloads de alta segurança no Amazon EKS)](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services (Proteção de serviços com tecnologia sem servidor e de contêiner)](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service (Práticas recomendadas de segurança para o serviço de metadados de instância do Amazon EC2)](https://youtu.be/2B5bhZzayjI) 

 **Exemplos relacionados:** 
+ [Laboratório: AWS Certificate Manager Request Public Certificate ](https://wellarchitectedlabs.com/security/200_labs/200_certificate_manager_request_public_certificate/)

# SEC06-BP04 Automatizar a proteção da computação
<a name="sec_protect_compute_auto_protection"></a>

 Automatize seus mecanismos de computação de proteção, incluindo gerenciamento de vulnerabilidades, redução da superfície de ataque e gerenciamento de recursos. A automação ajudará você a investir tempo para proteger outros aspectos da carga de trabalho e reduzir o risco de erros humanos. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Automatizar o gerenciamento de configuração: aplique e valide configurações seguras automaticamente usando uma ferramenta ou um serviço de gerenciamento de configuração. 
  +  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
  +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
  +  [Laboratório: Implantação automatizada da VPC](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 
  +  [Laboratório: Implantação automatizada da aplicação Web no EC2](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_EC2_Web_Application/README.html) 
+  Automatizar a aplicação de patches para instâncias do Amazon Elastic Compute Cloud(Amazon EC2): o Patch Manager do AWS Systems Manager automatiza o processo de aplicação de patches em instâncias gerenciadas com atualizações relacionadas à segurança e com outros tipos de atualizações. Você pode usar o gerenciador de patches para aplicar patches a sistemas operacionais e aplicações. 
  +  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
  +  [Correção centralizada de várias contas e várias regiões com automação do AWS Systems Manager](https://https://aws.amazon.com/blogs/mt/centralized-multi-account-and-multi-region-patching-with-aws-systems-manager-automation/) 
+  Implementar detecção e prevenção de intrusão: implemente uma ferramenta de detecção e prevenção de invasões para monitorar e interromper atividades maliciosas nas instâncias. 
+  Considerar as soluções de AWS Partner: os parceiros da AWS oferecem centenas de produtos líderes do setor que são equivalentes, idênticos ou se integram aos controles existentes nos seus ambientes on-premises. Esses produtos complementam os serviços da AWS já existentes para que os clientes possam implantar uma arquitetura de segurança abrangente e obter uma experiência mais uniforme na nuvem e no ambiente on-premises. 
  +  [Segurança da infraestrutura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
+  [Correção centralizada de várias contas e várias regiões com automação do AWS Systems Manager](https://aws.amazon.com/blogs/mt/centralized-multi-account-and-multi-region-patching-with-aws-systems-manager-automation/) 
+  [Segurança da infraestrutura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 
+  [Replacing a Bastion Host with Amazon EC2 Systems Manager (Como substituir um bastion host com o Amazon EC2 Systems Manager)](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Security Overview of AWS Lambda (Visão geral de segurança do AWS Lambda)](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Vídeos relacionados:** 
+  [Running high-security workloads on Amazon EKS (Execução de workloads de alta segurança no Amazon EKS)](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services (Proteção de serviços com tecnologia sem servidor e de contêiner)](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service (Práticas recomendadas de segurança para o serviço de metadados de instância do Amazon EC2)](https://youtu.be/2B5bhZzayjI) 

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada do firewall de aplicações Web](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 
+  [Laboratório: Implantação automatizada da aplicação Web no EC2](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_EC2_Web_Application/README.html) 

# SEC06-BP05 Permitir que as pessoas executem ações a uma distância
<a name="sec_protect_compute_actions_distance"></a>

 A remoção da capacidade de acesso interativo reduz o risco de erro humano e o potencial de configuração ou gerenciamento manual. Por exemplo, use um fluxo de trabalho de gerenciamento de alterações para implantar instâncias do Amazon Elastic Compute Cloud (Amazon EC2) usando infraestruturas como código e gerenciar instâncias do Amazon EC2 com ferramentas, como o AWS Systems Manager, em vez de permitir acesso direto, ou por meio de um host traga a sua própria licença. O AWS Systems Managerpode automatizar uma variedade de tarefas de manutenção e implantação, usando recursos que incluem fluxos de trabalho de [automação](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) [,](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), [documentos](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) (playbooks) e o [Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html). O AWS CloudFormation empilha a compilação com base em pipelines e pode automatizar tarefas de implantação e gerenciamento de infraestrutura sem usar diretamente o Console de gerenciamento da AWS ou APIs. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Substitua o acesso ao controle: substitua o acesso ao console (SSH ou RDP) a instâncias com o Run Command do AWS Systems Manager para automatizar tarefas de gerenciamento. 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
+  [Replacing a Bastion Host with Amazon EC2 Systems Manager (Como substituir um host traga a sua própria licença pelo Amazon EC2 Systems Manager)](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Security Overview of AWS Lambda (Visão geral de segurança do AWS Lambda)](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Vídeos relacionados:** 
+  [Running high-security workloads on Amazon EKS (Execução de workloads de alta segurança no Amazon EKS)](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services (Proteção de serviços com tecnologia sem servidor e de contêiner)](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service (Práticas recomendadas de segurança para o serviço de metadados de instância do Amazon EC2](https://youtu.be/2B5bhZzayjI) 

 **Exemplos relacionados:** 
+  [Laboratório: Implantação automatizada do firewall de aplicações Web](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 

# SEC06-BP06 Validar a integridade do software
<a name="sec_protect_compute_validate_software_integrity"></a>

 Implemente mecanismos (por exemplo, assinatura de código) para validar se o software, o código e as bibliotecas usados na workload são de fontes confiáveis e não foram adulterados. Por exemplo, você deve verificar o certificado de assinatura de código de binários e scripts para confirmar o autor e garantir que ele não tenha sido adulterado desde que foi criado pelo autor. [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) pode ajudar a garantir a confiança e a integridade do código gerenciando centralmente o ciclo de vida de assinatura de código, incluindo certificação de assinatura e chaves públicas e privadas. Você pode aprender a usar padrões avançados e práticas recomendadas para assinatura de código com o [AWS Lambda](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/). Além disso, uma soma de verificação do software que você faz download, em comparação com a soma de verificação do provedor, pode ajudar a garantir que ela não tenha sido adulterada. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Investigar os mecanismo: a assinatura de código é um mecanismo que pode ser usado para validar a integridade do software. 
  +  [NIST: Considerações de segurança para assinatura de código](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01262018.pdf) 

## Recursos
<a name="resources"></a>

**Documentos relacionados:** 
+ [AWS Signer](https://docs.aws.amazon.com/signer/index.html)
+ [New – Code Signing, a Trust and Integrity Control for AWS Lambda (Novo: assinatura de código, um controle de confiança e integridade para o AWS Lambda)](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/) 

# Proteção de dados
<a name="a-data-protection"></a>

**Topics**
+ [SEGURANÇA 7. Como classificar meus dados?](sec-07.md)
+ [SEGURANÇA 8. Como proteger seus dados em repouso?](sec-08.md)
+ [SEGURANÇA 9. Como proteger seus dados em trânsito?](sec-09.md)

# SEGURANÇA 7. Como classificar meus dados?
<a name="sec-07"></a>

A classificação serve para categorizar os dados com base em criticidade e confidencialidade para ajudá-lo a determinar os controles de proteção e retenção apropriados.

**Topics**
+ [SEC07-BP01 Identificar os dados em sua workload](sec_data_classification_identify_data.md)
+ [SEC07-BP02 Definir controles de proteção de dados](sec_data_classification_define_protection.md)
+ [SEC07-BP03 Automatizar a identificação e a classificação](sec_data_classification_auto_classification.md)
+ [SEC07-BP04 Definir o gerenciamento do ciclo de vida de dados](sec_data_classification_lifecycle_management.md)

# SEC07-BP01 Identificar os dados em sua workload
<a name="sec_data_classification_identify_data"></a>

É essencial compreender o tipo e a classificação de dados que sua workload está processando, os processos de negócios associados, onde os dados são armazenados e quem é o proprietário dos dados. Você também deve ter uma compreensão dos requisitos legais e de conformidade aplicáveis de sua workload e quais controles de dados precisam ser implementados. A identificação dos dados é a primeira etapa da jornada da classificação de dados. 

**Benefícios do estabelecimento desta prática recomendada:**

 A classificação dos dados possibilita que os proprietários da workload identifiquem os locais que armazenam dados sigilosos e determinem como esses dados devem ser acessados e compartilhados. 

 A classificação dos dados tem como objetivo responder às seguintes perguntas: 
+ **Qual tipo de dados você tem?**

  Podem ser dados como: 
  +  Propriedade intelectual (IP), como segredos comerciais, patentes ou contratos. 
  +  Informações de saúde protegidas (PHI), como registros médicos que contêm informações do histórico médico referente a um indivíduo. 
  +  Informações de identificação pessoal (PII), como nome, endereço, data de nascimento e ID nacional ou número de registro. 
  +  Dados do cartão de crédito, como o Número da conta principal (PAN), nome do titular do cartão, data de validade e número do código de serviço. 
  +  Onde os dados sigilosos são armazenados? 
  +  Quem pode acessar, modificar e excluir dados? 
  +  A compreensão das permissões do usuário é essencial na proteção contra o possível uso indevido de dados. 
+ **Quem pode realizar operações de criação, leitura, atualização e exclusão (CRUD)? **
  +  Considere a possível escalação de privilégios compreendendo quem pode gerenciar permissões aos dados. 
+ **Qual impacto nos negócios poderá ocorrer se os dados forem divulgados de forma acidental, alterados ou excluídos? **
  +  Entenda a consequência do risco se os dados forem modificados, excluídos ou divulgados acidentalmente. 

Ao responder a estas perguntas, você pode realizar as seguintes ações: 
+  Reduzir o escopo de dados sigilosos (como o número de locais de dados sigilosos) e limitar o acesso aos dados sigilosos somente para usuários aprovados. 
+  Obtenha um entendimento de diferentes tipos de dados para que você possa implementar técnicas e mecanismos de proteção de dados apropriados, como criptografia, prevenção da perda de dados e gerenciamento de identidade e acesso. 
+  Otimize os custos entregando os objetivos de controle certos para os dados. 
+  Responda às perguntas de modo confidencial de reguladores e auditores sobre os tipos e a quantidade de dados e como os dados de diferentes níveis de confidencialidade são isolados uns dos outros. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Classificação dos dados é o ato de identificar a confidencialidade dos dados. Ela pode envolver marcação para tornar os dados facilmente acessíveis e rastreáveis. A classificação de dados também reduz a duplicação de dados, o que pode ajudar a reduzir os custos de armazenamento e backup enquanto acelera o processo de pesquisa. 

 Utilize serviços, como o Amazon Macie para automatizar em grande escala a descoberta e a classificação de dados sigilosos. Outros serviços, como Amazon EventBridge e AWS Config, podem ser utilizados para automatizar a remediação de problemas de segurança de dados, como buckets do Amazon Simple Storage Service (Amazon S3) não criptografados e volumes do Amazon EC2 EBS ou recursos de dados não marcados. Para ter uma lista completa de integrações de serviços da AWS, consulte a [documentação do EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/event-types.html). 

 [A detecção de PII](https://docs.aws.amazon.com/comprehend/latest/dg/how-pii.html) em dados não estruturados, como e-mails de clientes, tickets de suporte, análises de produtos e redes sociais, é possível [com o uso do Amazon Comprehend](https://aws.amazon.com/blogs/machine-learning/detecting-and-redacting-pii-using-amazon-comprehend/), que é um serviço de processamento de linguagem natural (PLN) que utiliza machine learning (ML) para encontrar insights e relacionamentos, como pessoas, locais, sentimentos e tópicos em texto não estruturado. Para ter uma lista de serviços da AWS que podem auxiliar na identificação dos dados, consulte [Técnicas comuns para detectar dados PHI e PII com o uso de serviços da AWS](https://aws.amazon.com/blogs/industries/common-techniques-to-detect-phi-and-pii-data-using-aws-services/). 

 Outro método compatível com a classificação e a proteção de dados é a [marcação de recursos da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html). A marcação possibilita atribuir metadados aos seus recursos da AWS que você pode utilizar para gerenciar, identificar, organizar, procurar e filtrar recursos. 

 Em alguns casos, você pode optar por marcar recursos inteiros (como um bucket do S3), especialmente quando uma workload ou um serviço específico deve armazenar processos ou transmissões de classificação de dados já conhecidos. 

 Quando apropriado, é possível marcar um bucket do S3 em vez de objetos individuais para facilidade de administração e manutenção de segurança. 

### Etapas da implementação
<a name="implementation-steps"></a>

**Detectar dados sigilosos no Amazon S3: **

1.  Antes de começar, você deve ter permissões apropriadas para acessar o console do Amazon Macie e as operações de API. Para ter detalhes adicionais, consulte [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html). 

1.  Utilize o Amazon Macie para realizar a descoberta de dados automatizada quando seus dados sigilosos residem no [Amazon S3](https://aws.amazon.com/s3/). 
   +  Utilize o guia [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) para configurar um repositório para os resultados da descoberta de dados sigilosos e criar um trabalho de descoberta de dados sigilosos. 
   +  [Como utilizar o Amazon Macie para visualizar dados sigilosos em buckets do S3.](https://aws.amazon.com/blogs/security/how-to-use-amazon-macie-to-preview-sensitive-data-in-s3-buckets/) 

      Por padrão, o Macie analisa objetos utilizando o conjunto de identificadores de dados gerenciados que recomendamos para a descoberta automatizada de dados sigilosos. É possível ajustar a análise configurando o Macie para utilizar identificadores de dados gerenciados específicos, identificadores de dados personalizados e listas de permissões quando ele realiza a descoberta automatizada de dados sigilosos para a sua conta ou organização. Você pode ajustar o escopo da análise excluindo buckets específicos (por exemplo, buckets do S3 que geralmente armazenam dados de registro em log da AWS). 

1.  Para configurar e utilizar a descoberta automatizada de dados sigilosos, consulte [Realizar a descoberta automatizada de dados sigilosos com o Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/discovery-asdd-account-manage.html). 

1.  Você também pode considerar [Descoberta automatizada de dados para o Amazon Macie](https://aws.amazon.com/blogs/aws/automated-data-discovery-for-amazon-macie/). 

**Detectar dados sigilosos no Amazon RDS: **

 Para ter mais informações sobre a descoberta de dados em bancos de dados [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/), consulte [Habilitar a classificação de dados para o banco de dados Amazon RDS com o Macie](https://aws.amazon.com/blogs/security/enabling-data-classification-for-amazon-rds-database-with-amazon-macie/). 

**Detectar dados sigilosos no DynamoDB: **
+  [Detectar dados sigilosos no DynamoDB com Macie](https://aws.amazon.com/blogs/security/detecting-sensitive-data-in-dynamodb-with-macie/) explica como utilizar o Amazon Macie para detectar dados sigilosos em tabelas do [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) exportando os dados para o Amazon S3 para verificação. 

** Soluções de parceiros da AWS: **
+  Considere utilizar nossa AWS Partner Network extensiva. Os parceiros da AWS têm ferramentas e frameworks de conformidade extensas que se integram diretamente aos serviços da AWS. Os parceiros podem oferecer uma solução de governança e conformidade personalizada para ajudar você a atender às suas necessidades organizacionais. 
+  Para saber sobre as soluções personalizadas em classificação de dados, consulte [Governança de dados na era dos requisitos de regulamento e conformidade](https://aws.amazon.com/big-data/featured-partner-solutions-data-governance-compliance/). 

 É possível aplicar automaticamente os padrões de marcação que sua organização adota criando e implantando políticas com o uso do AWS Organizations. As políticas de tag possibilitam especificar regras que definem nomes de chave válidas e quais valores são válidos para cada chave. É possível optar somente por monitorar, que oferece a você uma oportunidade de avaliar e limpar suas tags existentes. Depois que suas tags estiverem em conformidade com seus padrões escolhidos, você poderá ativar a aplicação nas políticas de tag a fim de impedir que tags sem conformidade sejam criadas. Para ter mais detalhes, consulte [Proteger tags de recursos utilizadas para autorização utilizando uma política de controle de serviço no AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) e o exemplo de política em [Impedir que as tags sejam modificadas, exceto por principais autorizados](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin). 
+  Para começar a utilizar políticas de tag no [AWS Organizations](https://aws.amazon.com/organizations/), é altamente recomendável que você siga o fluxo de trabalho em [Conceitos básicos de políticas de tag](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-getting-started.html) antes de passar para políticas de tag mais avançadas. Compreender os efeitos de anexar uma política de tag simples a uma conta antes de expandir para uma unidade organizacional (UO) ou uma organização inteira permite ver os efeitos de uma política de tag antes de aplicar a conformidade com a política de tag. [Conceitos básicos de políticas de tag](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-getting-started.html) oferece links para instruções de tarefas relacionadas a política mais avançadas. 
+  Considere a avaliação de outros [serviços e recursos do AWS](https://docs.aws.amazon.com/whitepapers/latest/data-classification/using-aws-cloud-to-support-data-classification.html#aws-services-and-features) compatíveis com a classificação de dados, que estão listados no whitepaper [Classificação de dados](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) 
+  [Descoberta automatizada de dados com o Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/discovery-asdd.html) 
+  [Conceitos básicos de políticas de tag](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-getting-started.html) 
+  [Detectar entidades de PII](https://docs.aws.amazon.com/comprehend/latest/dg/how-pii.html) 

 **Blogs relacionados:** 
+  [Como utilizar o Amazon Macie para visualizar dados sigilosos em buckets do S3.](https://aws.amazon.com/blogs/security/how-to-use-amazon-macie-to-preview-sensitive-data-in-s3-buckets/) 
+  [Realizar a descoberta automatizada de dados sigilosos com o Amazon Macie](https://aws.amazon.com/blogs/aws/automated-data-discovery-for-amazon-macie/) 
+  [Técnicas comuns para detectar dados PHI e PII com o uso de serviços da AWS](https://aws.amazon.com/blogs/industries/common-techniques-to-detect-phi-and-pii-data-using-aws-services/) 
+  [Detectar e editar PII com o uso do Amazon Comprehend](https://aws.amazon.com/blogs/machine-learning/detecting-and-redacting-pii-using-amazon-comprehend/) 
+  [Proteger tags de recursos usadas para autorização utilizando uma política de controle de serviços no AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) 
+  [Habilitar a classificação do banco de dados Amazon RDS com o Macie](https://aws.amazon.com/blogs/security/enabling-data-classification-for-amazon-rds-database-with-amazon-macie/) 
+  [Detectar dados sigilosos no DynamoDB com o Macie](https://aws.amazon.com/blogs/security/detecting-sensitive-data-in-dynamodb-with-macie/) 

 **Vídeos relacionados:** 
+  [Segurança dos dados orientada a eventos com o uso do Amazon Macie](https://www.youtube.com/watch?v=onqA7MJssoU) 
+  [Amazon Macie para proteção e governança de dados](https://www.youtube.com/watch?v=SmMSt0n6a4k) 
+  [Ajustar descobertas de dados sigilosos com listas de permissão](https://www.youtube.com/watch?v=JmQ_Hybh2KI) 

# SEC07-BP02 Definir controles de proteção de dados
<a name="sec_data_classification_define_protection"></a>

 Proteja os dados de acordo com seu nível de classificação. Por exemplo, proteja dados classificados como públicos usando recomendações relevantes enquanto protege dados confidenciais com controles adicionais. 

Usando tags de recursos, separar contas da AWS por confidencialidade (e potencialmente também por advertência, enclave ou comunidade de interesse), políticas do IAM, SCPs do AWS Organizations, AWS Key Management Service (AWS KMS) e AWS CloudHSM, você pode definir e implementar as políticas de classificação e proteção de dados com criptografia. Por exemplo, se você tiver buckets do S3 que contêm dados altamente críticos ou instâncias do Amazon Elastic Compute Cloud (Amazon EC2) que processam dados confidenciais, eles poderão ser marcados com uma tag `Project=ABC` . Somente a equipe imediata sabe o que o código do projeto significa e fornece meios de usar o controle de acesso baseado em atributos. Você pode definir os níveis de acesso às chaves de criptografia do AWS KMS por meio de políticas de chave e concessões para garantir que somente os serviços apropriados tenham acesso ao conteúdo confidencial por meio de um mecanismo seguro. Se você estiver tomando decisões de autorização com base em tags, certifique-se de que as permissões nas tags sejam definidas adequadamente usando políticas de tags no AWS Organizations.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Defina o esquema de identificação e classificação de dados: a identificação e a classificação de seus dados são realizadas para avaliar o potencial impacto e o tipo de dados que você está armazenando e quem deve acessá-los. 
  +  [Documentação da AWS](https://docs.aws.amazon.com/) 
+  Descubra os controles disponíveis da AWS: descubra os controles de segurança para os serviços da AWS que você usa ou planeja usar. Muitos serviços têm uma seção de segurança em sua documentação. 
  +  [Documentação da AWS](https://docs.aws.amazon.com/) 
+  Identificar recursos de conformidade da AWS: identifique os recursos da AWS disponíveis para ajudar. 
  +  [https://aws.amazon.com/compliance/](https://aws.amazon.com/compliance/?ref=wellarchitected) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Documentação da AWS](https://docs.aws.amazon.com/) 
+  [Whitepaper Classificação de dados](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) 
+  [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) 
+  [Texto ausente](https://aws.amazon.com/compliance/) 

 **Vídeos relacionados:** 
+  [Introducing the New Amazon Macie (Apresentação do novo Amazon Macie)](https://youtu.be/I-ewoQekdXE) 

# SEC07-BP03 Automatizar a identificação e a classificação
<a name="sec_data_classification_auto_classification"></a>

 automatizar a identificação e a classificação de dados pode ajudar a implementar os controles corretos. O uso de automação para isso, em vez de acesso direto de uma pessoa, reduz o risco de erros humanos e exposição. Você deve avaliar o uso de uma ferramenta, como o [Amazon Macie](https://aws.amazon.com/macie/), que usa machine learning para descobrir, classificar e proteger automaticamente dados confidenciais na AWS. O Amazon Macie reconhece dados confidenciais, como informações de identificação pessoal (PII) ou propriedade intelectual, e fornece painéis e alertas que dão visibilidade sobre como esses dados estão sendo acessados ou movidos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Use o Amazon Simple Storage Service (Amazon S3) Inventory: o Amazon S3 Inventory é uma das ferramentas que você pode usar para auditar e gerar relatórios sobre o status de replicação e criptografia de seus objetos. 
  +  [Amazon S3 Inventory](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html) 
+  Considere o Amazon Macie: O Amazon Macie usa o machine learning para descobrir e classificar automaticamente os dados armazenados no Amazon S3.
  +  [Amazon Macie](https://aws.amazon.com/macie/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon Macie](https://aws.amazon.com/macie/) 
+  [Amazon S3 Inventory](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html) 
+  [Whitepaper Classificação de dados](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) 
+  [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) 

 **Vídeos relacionados:** 
+  [Introducing the New Amazon Macie (Apresentação do novo Amazon Macie)](https://youtu.be/I-ewoQekdXE) 

# SEC07-BP04 Definir o gerenciamento do ciclo de vida de dados
<a name="sec_data_classification_lifecycle_management"></a>

 sua estratégia de ciclo de vida definida deve ser baseada no nível de confidencialidade, bem como nos requisitos legais e organizacionais. Aspectos como a duração pela qual você retém dados, processos de destruição de dados, gerenciamento de acesso a dados, transformação de dados e compartilhamento de dados devem ser considerados. Ao escolher uma metodologia de classificação de dados, equilibre usabilidade e acesso. Considere também os vários níveis de acesso e nuances para implementar uma abordagem segura, mas utilizável, para cada nível. Sempre use uma abordagem de defesa detalhada e reduza o acesso humano a dados e mecanismos para transformar, excluir ou copiar dados. Por exemplo, exija que os usuários se autentiquem fortemente em uma aplicação e conceda a ela, e não aos usuários, a permissão de acesso necessária para executar uma ação a distância. Além disso, garanta que os usuários venham de um caminho de rede confiável e exijam acesso às chaves de descriptografia. Use ferramentas como painéis ou relatórios automatizados para fornecer aos usuários informações extraídas dos dados e não acesso direto aos dados. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Identificar tipos de dados: identifique os tipos de dados que você está armazenando ou processando em sua workload. Esses dados podem ser texto, imagens, bancos de dados binários, entre outros. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Whitepaper Classificação de dados](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) 
+  [Conceitos básicos do Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) 

 **Vídeos relacionados:** 
+  [Introducing the New Amazon Macie (Apresentação do novo Amazon Macie)](https://youtu.be/I-ewoQekdXE) 

# SEGURANÇA 8. Como proteger seus dados em repouso?
<a name="sec-08"></a>

Proteja seus dados em repouso implementando vários controles para reduzir o risco de acesso não autorizado ou manuseio incorreto.

**Topics**
+ [SEC08-BP01 Implementar gerenciamento de chaves seguro](sec_protect_data_rest_key_mgmt.md)
+ [SEC08-BP02 Aplicar criptografia em repouso](sec_protect_data_rest_encrypt.md)
+ [SEC08-BP03 Automatizar a proteção de dados em repouso](sec_protect_data_rest_automate_protection.md)
+ [SEC08-BP04 Impor o controle de acesso](sec_protect_data_rest_access_control.md)
+ [SEC08-BP05 Usar mecanismos para evitar que as pessoas acessem os dados](sec_protect_data_rest_use_people_away.md)

# SEC08-BP01 Implementar gerenciamento de chaves seguro
<a name="sec_protect_data_rest_key_mgmt"></a>

 O gerenciamento seguro de chaves inclui o armazenamento, a rotação, o controle de acesso e o monitoramento do material essencial necessário para proteger os dados em repouso para sua workload. 

 **Resultado desejado:** um mecanismo de gerenciamento de chaves escalável, repetível e automatizado. O mecanismo deve fornecer a capacidade de impor o acesso de privilégio mínimo ao material essencial e fornecer o equilíbrio correto entre disponibilidade, confidencialidade e integridade das chaves. O acesso às chaves deve ser monitorado e o material da chave deve ser rotacionado por meio de um processo automatizado. O material de chave nunca deve estar acessível a identidades humanas. 

**Antipadrões comuns:** 
+  Acesso humano a material de chave não criptografado. 
+  Criação de algoritmos criptográficos personalizados. 
+  Permissões excessivamente amplas para acessar materiais importantes. 

 **Benefícios de estabelecer esta prática recomendada:** Ao estabelecer um mecanismo seguro de gerenciamento de chaves para sua workload, você pode ajudar a proteger seu conteúdo contra acesso não autorizado. Além disso, você pode estar sujeito aos requisitos regulamentares para criptografar seus dados. Uma solução eficaz de gerenciamento de chaves pode fornecer mecanismos técnicos alinhados a essas regulamentações para proteger o material chave. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Muitos requisitos regulatórios e práticas recomendadas incluem a criptografia de dados em repouso como um controle de segurança fundamental. Para cumprir esse controle, sua workload precisa de um mecanismo para armazenar e gerenciar com segurança o material chave usado para criptografar seus dados em repouso. 

 A AWS oferece o AWS Key Management Service (AWS KMS) para fornecer armazenamento durável, seguro e redundante para chaves do AWS KMS. [Muitos serviços da AWS se integram com o AWS KMS](https://aws.amazon.com/kms/features/#integration) para oferecer suporte à criptografia de seus dados. O AWS KMS usa módulos de segurança de hardware validados pelo FIPS 140-2 Nível 3 para proteger suas chaves. Não há mecanismo para exportar chaves do AWS KMS em texto simples. 

 Ao implantar workloads usando uma estratégia de várias contas, isso é considerado [prática recomendada](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/application.html#app-kms) para manter chaves do AWS KMS na mesma conta da workload que as usa. Nesse modelo distribuído, a responsabilidade pelo gerenciamento das chaves do AWS KMS é da equipe de aplicações. Em outros casos de uso, as organizações podem optar por armazenar as chaves do AWS KMS em uma conta centralizada. Essa estrutura centralizada requer políticas adicionais para permitir o acesso entre contas necessário para que a conta da workload acesse as chaves armazenadas na conta centralizada, mas pode ser mais aplicável em casos de uso em que uma única chave é compartilhada entre várias Contas da AWS. 

 Independentemente de onde o material da chave esteja armazenado, o acesso à chave deve ser rigorosamente controlado por meio do uso de [políticas de chave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) e políticas do IAM. Políticas de chave são a principal forma de controlar o acesso a uma chave do AWS KMS. Além disso, concessões à chave do AWS KMS podem fornecer acesso a serviços da AWS para criptografar e descriptografar dados em seu nome. Reserve um tempo para revisar as [práticas recomendadas para controle de acesso às chaves do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies-best-practices.html). 

 É uma prática recomendada monitorar o uso de chaves de criptografia para detectar padrões de acesso incomuns. As operações realizadas usando chaves gerenciadas pela AWS e chaves gerenciadas pelo cliente armazenadas no AWS KMS podem ser registradas no AWS CloudTrail e devem ser revisadas periodicamente. Atenção especial deve ser dada ao monitoramento dos principais eventos de destruição. Para mitigar a destruição acidental ou maliciosa de material de chave, os eventos de destruição da chave não excluem o material da chave imediatamente. As tentativas de excluir as chaves no AWS KMS estão sujeitas a um [período de espera](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html#deleting-keys-how-it-works), cujo padrão é de 30 dias, dando aos administradores tempo para revisar essas ações e reverter a solicitação, se necessário. 

 A maioria dos serviços da AWS usam o AWS KMS de forma transparente para você. Seu único requisito é decidir se quer usar uma chave gerenciada pela AWS ou gerenciada pelo cliente. Se sua workload exigir o uso direto de AWS KMS para criptografar ou descriptografar dados, a prática recomendada é usar [criptografia envelopada](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) para proteger seus dados. O [SDK de criptografia da AWS](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) pode fornecer às suas aplicações primitivas de criptografia do lado do cliente para implementar a criptografia envelopada e integrar com o AWS KMS. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Determine as opções adequadas [de gerenciamento de chaves](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt) (gerenciado pela AWS ou gerenciado pelo cliente) para a chave. 
   +  Para facilitar o uso, a AWS oferece, para a maioria dos serviços, chaves de propriedade da AWS e gerenciadas por ela, que fornecem capacidade de criptografia em repouso sem a necessidade de gerenciar materiais ou políticas de chaves. 
   +  Ao usar chaves gerenciadas pelo cliente, considere o armazenamento de chaves padrão para fornecer o melhor equilíbrio entre agilidade, segurança, soberania de dados e disponibilidade. Outros casos de uso podem exigir o uso de armazenamentos de chaves personalizadas com [AWS CloudHSM](https://aws.amazon.com/cloudhsm/) ou o [armazenamento de chaves externo](https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html). 

1.  Analise a lista de serviços que você está usando para sua workload para entender como o AWS KMS se integra ao serviço. Por exemplo, as instâncias do EC2 podem usar volumes criptografados do EBS, verificando se os snapshots do Amazon EBS criados a partir desses volumes também são criptografados usando uma chave gerenciada pelo cliente e mitigando a divulgação acidental de dados de snapshots não criptografados. 
   +  [Como os serviços da AWS são usados no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/service-integration.html) 
   +  Para obter informações detalhadas sobre as opções de criptografia que um serviço da AWS oferece, consulte o tópico Criptografia em repouso no guia do usuário ou no guia do desenvolvedor do serviço. 

1.  Implemente o AWS KMS: o AWS KMS simplifica a criação e o gerenciamento de chaves e o controle do uso da criptografia em uma ampla variedade de serviços da AWS e em suas aplicações. 
   +  [Conceitos básicos: AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html) 
   +  Revise as [práticas recomendadas para controle de acesso às chaves do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies-best-practices.html). 

1.  Considere o AWS Encryption SDK: use a integração do AWS Encryption SDK com o AWS KMS quando sua aplicação precisar criptografar dados no lado do cliente. 
   +  [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) 

1.  Habilite o [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) para revisar e notificar automaticamente se houver políticas de chave do AWS KMS excessivamente amplas. 

1.  Habilite o [Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html) para receber notificações se houver políticas de chaves configuradas incorretamente, chaves programadas para exclusão ou chaves sem a rotação automática ativada. 

1.  Determine o nível de registro em log apropriado para suas chaves do AWS KMS. Como as chamadas para o AWS KMS, incluindo eventos somente para leitura, são registradas em log, os logs do CloudTrail associados ao AWS KMS podem se tornar volumosos. 
   +  Algumas organizações preferem registrar a atividade de log do AWS KMS em uma trilha separada. Para obter mais detalhes, consulte a seção [Registro em log de chamadas de API do AWS KMS com CloudTrail](https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html) do guia do desenvolvedor do AWS KMS. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) 
+  [Ferramentas e serviços criptográficos da AWS](https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-overview.html) 
+  [Como proteger dados do Amazon S3 com o uso de criptografia](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) 
+  [Criptografia envelopada](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) 
+  [Promessa de soberania digital](https://aws.amazon.com/blogs/security/aws-digital-sovereignty-pledge-control-without-compromise/) 
+  [Desmistificação das operações de chave do AWS KMS, traga sua própria chave, armazenamento de chaves personalizado e portabilidade de texto cifrado](https://aws.amazon.com/blogs/security/demystifying-kms-keys-operations-bring-your-own-key-byok-custom-key-store-and-ciphertext-portability/) 
+  [Detalhes criptográficos do AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 

 **Vídeos relacionados:** 
+  [How Encryption Works in AWS (Como funciona a criptografia na AWS)](https://youtu.be/plv7PQZICCM) 
+  [Securing Your Block Storage on AWS (Proteger seu armazenamento em bloco na AWS)](https://youtu.be/Y1hE1Nkcxs8) 
+  [AWS data protection: Using locks, keys, signatures, and certificates (Proteção de dados da AWS: uso de travas, chaves, assinaturas e certificados)](https://www.youtube.com/watch?v=lD34wbc7KNA) 

 **Exemplos relacionados:** 
+  [Implemente mecanismos avançados de controle de acesso usando o AWS KMS](https://catalog.workshops.aws/advkmsaccess/en-US/introduction) 

# SEC08-BP02 Aplicar criptografia em repouso
<a name="sec_protect_data_rest_encrypt"></a>

 É necessário implementar o uso de criptografia para dados em repouso. A criptografia mantém a confidencialidade dos dados sigilosos em caso de acesso não autorizado ou divulgação acidental. 

 **Resultado desejado:** os dados privados devem ser criptografados por padrão quando em repouso. A criptografia ajuda a manter a confidencialidade dos dados e oferece uma camada adicional de proteção contra a divulgação intencional ou acidental de dados ou exfiltração. Dados criptografados não podem ser lidos nem acessados sem primeiro descriptografá-los. Todos os dados armazenados não criptografados devem ser inventariados e controlados. 

 **Antipadrões comuns:** 
+  Não utilizar configurações de criptografia por padrão. 
+  Conceder acesso excessivamente permissivo para chaves de descriptografia. 
+  Não monitorar o uso de chaves de criptografia e descriptografia. 
+  Armazenar dados não criptografados. 
+  Utilizar a mesma chave de criptografia para todos os dados, seja qual for o uso, os tipos e a classificação de dados. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Mapeie as chaves de criptografia às classificações de dados em suas workloads. Essa abordagem ajuda a proteger-se contra o acesso excessivamente permissivo ao utilizar uma chave única ou um número muito pequeno de chaves de criptografia para seus dados (consulte [SEC07-BP01 Identificar os dados em sua workload](sec_data_classification_identify_data.md)). 

 O AWS Key Management Service (AWS KMS) integra-se a muitos serviços da AWS para facilitar a criptografia de seus dados em repouso. Por exemplo, no Amazon Simple Storage Service (Amazon S3), você pode definir a [criptografia padrão](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html) em um bucket para que os novos objetos sejam criptografados automaticamente. Ao utilizar o AWS KMS, considere o nível de restrição necessário para os dados. Chaves do AWS KMS controladas por serviço e padrão são gerenciadas e utilizadas em seu nome pelo AWS. Para dados sigilosos que exijam acesso refinado à chave de criptografia subjacente, considere chaves gerenciadas pelo cliente (CMKs). Você tem total controle sobre as CMKs, como gerenciamento de alternância e acesso pelo uso de políticas de chave. 

 Além disso, o [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) e o [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) são compatíveis com a imposição de criptografia ao definir a criptografia padrão. Você pode usar o [Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) para conferir automaticamente se está usando criptografia, por exemplo, [volumes do Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html), instâncias do [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html) e [buckets do Amazon S3](https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html). 

 A AWS também oferece operações de criptografia do lado do cliente, possibilitando que você criptografe os dados antes de fazer upload deles para a nuvem. O AWS Encryption SDKoferece uma forma de criptografar seus dados utilizando a [criptografia envelopada](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping). Você fornece a chave de encerramento, e o AWS Encryption SDK gera uma chave de dados exclusiva para cada objeto de dados que ele criptografa. Considere utilizar o AWS CloudHSM se precisar de um módulo de segurança de hardware de um locatário (HSM) gerenciado. O AWS CloudHSM possibilita gerar, importar e gerenciar chaves criptográficas em um HSM validado de nível 3 FIPS 140-2. Alguns casos de uso do AWS CloudHSM incluem proteger chaves privadas para emitir uma autoridade de certificado (CA) e ativar a criptografia de dados transparente (TDE) para bancos de dados Oracle. O AWS CloudHSM Client SDK oferece software que possibilita criptografar dados do lado do cliente com chaves armazenadas no AWS CloudHSM antes de fazer upload de seus dados para AWS. O Amazon DynamoDB Encryption Client também possibilita criptografar e assinar itens antes de fazer upload para uma tabela do DynamoDB. 

 **Etapas da implementação** 
+  **Impor criptografia em repouso para o Amazon S3:** implemente a [criptografia padrão do bucket do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html). 

   **Configurar a [criptografia padrão para volumes do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html):** especifique que você deseja que todos os volumes do Amazon EBS recém-criados sejam criados em formato criptografado, com a opção de usar a chave padrão fornecida pela AWS ou uma chave que você criar. 

   **Configurar imagens de máquina da Amazon (AMIs) criptografadas:** a cópia de uma AMI existente com criptografia habilitada criptografará automaticamente os volumes raiz e os snapshots. 

   **Configurar a [criptografia do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html):** configure a criptografia para seus clusters de banco de dados Amazon RDS e snapshots em repouso utilizando a opção de criptografia. 

   **Criar e configurar chaves do AWS KMS com políticas que limitem o acesso às entidades principais apropriadas para cada classificação de dados:** por exemplo, crie uma chave do AWS KMS para criptografar dados de produção e uma chave diferente para criptografar dados de desenvolvimento ou teste. Você também pode conceder acesso de chave a outras Contas da AWS. Considere ter contas diferentes para seus ambientes de desenvolvimento e produção. Se seu ambiente de produção precisar descriptografar artefatos na conta de desenvolvimento, você poderá editar a política de CMK utilizada para criptografar os artefatos de desenvolvimento a fim de conferir à conta de produção a capacidade de descriptografar esses artefatos. O ambiente de produção pode, então, ingerir os dados descriptografados para uso na produção. 

   **Configurar a criptografia em serviços da AWS adicionais:** para outros serviços da AWS utilizados, leia a [documentação de segurança](https://docs.aws.amazon.com/security/) do serviço em questão para determinar as opções de criptografia do serviço. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Ferramentas de criptografia da AWS](https://docs.aws.amazon.com/aws-crypto-tools) 
+  [Documentação da AWS](https://docs.aws.amazon.com/) 
+  [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) 
+  [Whitepaper de detalhes criptográficos do AWS KMS](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 
+  [AWS Key Management Service](https://aws.amazon.com/kms) 
+  [Ferramentas e serviços criptográficos da AWS](https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-overview.html) 
+  [Criptografia do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) 
+  [Criptografia padrão de volumes do Amazon EBS](https://aws.amazon.com/blogs/aws/new-opt-in-to-default-encryption-for-new-ebs-volumes/) 
+  [Criptografar recursos do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) 
+  [Como ativo a criptografia padrão para um bucket do Amazon S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/default-bucket-encryption.html) 
+  [Proteger dados do Amazon S3 com o uso de criptografia](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) 

 **Vídeos relacionados:** 
+  [Como a criptografia funciona na AWS](https://youtu.be/plv7PQZICCM) 
+  [Proteger o armazenamento em bloco na AWS](https://youtu.be/Y1hE1Nkcxs8) 

# SEC08-BP03 Automatizar a proteção de dados em repouso
<a name="sec_protect_data_rest_automate_protection"></a>

 Use ferramentas automatizadas para validar e impor controles de dados em repouso continuamente, por exemplo, verificar se há apenas recursos de armazenamento criptografados. Você pode [automatizar a validação de que todos os volumes do EBS são criptografados](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html) com o uso do [Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html). [AWS Security Hub CSPM](http://aws.amazon.com/security-hub/) também pode verificar vários controles diferentes por meio de verificações automatizadas em relação a padrões de segurança. Além disso, o Regras do AWS Config pode [corrigir recursos não compatíveis automaticamente](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html#setup-autoremediation). 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation_guidance"></a>

 *Dados em repouso* representam todos os dados mantidos no armazenamento não volátil por qualquer período na carga de trabalho. Isso inclui armazenamento em bloco, armazenamento de objetos, bancos de dados, arquivos, dispositivos IoT e qualquer outro meio de armazenamento no qual os dados persistam. Proteger seus dados em repouso reduz o risco de acesso não autorizado quando a criptografia e os controles de acesso adequados são implementados. 

 Garantir a criptografia em repouso: garanta que a única maneira de armazenar dados seja usando a criptografia. O AWS KMS se integra perfeitamente a muitos serviços da AWS para facilitar a criptografia de todos os seus dados em repouso. Por exemplo, no Amazon Simple Storage Service (Amazon S3), você pode definir a [criptografia padrão](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html) em um bucket para que todos os novos objetos sejam criptografados automaticamente. Além disso, o [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) e [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) oferecem suporte à imposição de criptografia ao definir a criptografia padrão. Você pode usar o [AWS Managed Config Rules](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) para verificar automaticamente se você está usando criptografia, por exemplo, para [Volumes do EBS](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html), [instâncias do Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html)e aos [Amazon S3](https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Ferramentas de criptografia da AWS](https://docs.aws.amazon.com/aws-crypto-tools) 
+  [SDK de criptografia da AWS](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) 

 **Vídeos relacionados:** 
+  [How Encryption Works in AWS (Como a criptografia funciona na AWS)](https://youtu.be/plv7PQZICCM) 
+  [Securing Your Block Storage on AWS (Como proteger o armazenamento em bloco na AWS)](https://youtu.be/Y1hE1Nkcxs8) 

# SEC08-BP04 Impor o controle de acesso
<a name="sec_protect_data_rest_access_control"></a>

 Para ajudar a proteger seus dados em repouso, implemente o controle de acesso utilizando mecanismos, como isolamento e versionamento, e aplique o princípio de privilégio mínimo. Evite conceder acesso público aos seus dados. 

**Resultado desejado:** garantir que somente usuários autorizados possam acessar os dados conforme a necessidade. Proteger seus dados com backups regulares e versionamento a fim de impedir a modificação ou a exclusão de dados intencionais ou acidentais. Isolar dados críticos de outros dados a fim de proteger a confidencialidade e a integridade deles. 

**Antipadrões comuns:**
+  Armazenar dados com requisitos de confidencialidade ou classificações diferentes juntos. 
+  Utilizar permissões excessivamente permissivas em chaves de descriptografia. 
+  Classificar dados de modo inadequado. 
+  Não reter backups detalhados de dados importantes. 
+  Conceder acesso persistente a dados de produção. 
+  Não auditar o acesso aos dados nem rever as permissões regularmente 

**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Vários controles podem ajudar a proteger seus dados em repouso, por exemplo, acesso (utilizando privilégio mínimo), isolamento e versionamento. Deve ser feita a auditoria de acesso aos seus dados com os mecanismos de detecção, como AWS CloudTrail e os logs de nível de serviço, como os logs de acesso do Amazon Simple Storage Service (Amazon S3). Você deve inventariar quais dados são acessíveis publicamente e criar um plano para reduzir a quantidade de dados disponíveis ao longo do tempo. 

 O Amazon Glacier Vault Lock e o Amazon S3 Object Lock fornecem controle de acesso obrigatório para os objetos no Amazon S3. Assim que uma política de cofre é bloqueada com a opção de conformidade, nem mesmo o usuário raiz pode alterá-la até que o bloqueio expire. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Aplicar o controle de acesso**: aplique o controle de acesso com privilégios mínimos, incluindo acesso a chaves de criptografia. 
+  **Dados separados com base em diferentes níveis de classificação**: use diferentes Contas da AWS para níveis de classificação de dados e gerencie essas contas com o [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). 
+  **Analisar as políticas do AWS Key Management Service (AWS KMS)**: [analise o nível de acesso](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) concedido nas políticas do AWS KMS. 
+  **Revisar as permissões de objeto e de bucket do Amazon S3**: revise regularmente o nível de acesso concedido nas políticas de bucket do S3. Uma das práticas recomendadas é evitar buckets que possam ser lidos ou gravados publicamente. Considere o uso do [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) para detectar buckets que estão disponíveis publicamente e do Amazon CloudFront para fornecer conteúdo do Amazon S3. Garanta que os buckets que não devem permitir acesso público sejam configurados adequadamente para evitar o acesso público. Por padrão, todos os buckets do S3 são privados e só ser acessados por usuários que receberam explicitamente esse acesso. 
+  **Ativar o [AWS IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/what-is-access-analyzer.html):** o IAM Access Analyzer analisa os buckets do Amazon S3 e gera uma descoberta quando [uma política do S3 concede acesso a uma entidade externa.](https://docs.aws.amazon.com//latest/UserGuide/access-analyzer-resources.html#access-analyzer-s3) 
+  **Habilitar o [versionamento do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html) e o [bloqueio de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html)** quando apropriado. 
+  **Utilizar o [Amazon S3 Inventory](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html)**: o Amazon S3 Inventory pode ser usado para auditar e gerar relatórios sobre o status de replicação e criptografia de seus objetos do S3. 
+  **Revisar as permissões do [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html) e do [compartilhamento de AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharing-amis.html)**: as permissões de compartilhamento podem permitir que imagens e volumes sejam compartilhados com Contas da AWS externas à sua workload. 
+  **Revise os compartilhamentos do [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) periodicamente para determinar se os recursos devem continuar a ser compartilhados.** O Resource Access Manager possibilita compartilhar recursos, como políticas do AWS Network Firewall, regras do Amazon Route 53 Resolver e sub-redes em suas Amazon VPCs. Faça auditoria em recursos compartilhados regularmente e interrompa o compartilhamento dos que não precisem mais ser compartilhados. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [SEC03-BP01 Definir requisitos de acesso](sec_permissions_define.md) 
+  [SEC03-BP02 Conceder acesso com privilégio mínimo](sec_permissions_least_privileges.md) 

 **Documentos relacionados:** 
+  [Whitepaper de detalhes criptográficos do AWS KMS](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 
+  [Introdução ao gerenciamento de permissões de acesso aos seus recursos do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/intro-managing-access-s3-resources.html) 
+  [Visão geral do gerenciamento de acesso dos recursos do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html) 
+  [Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) 
+  [Amazon S3 \$1 Amazon CloudFront: uma combinação perfeita na nuvem](https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/) 
+  [Usar versionamento](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html) 
+  [Bloquear objetos usando o Bloqueio de objetos do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lock.html) 
+  [Compartilhar um snapshot do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html) 
+  [AMIs compartilhadas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharing-amis.html) 
+  [Hospedar uma aplicação de uma página no Amazon S3](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html) 

 **Vídeos relacionados:** 
+  [Proteger o armazenamento em bloco na AWS](https://youtu.be/Y1hE1Nkcxs8) 

# SEC08-BP05 Usar mecanismos para evitar que as pessoas acessem os dados
<a name="sec_protect_data_rest_use_people_away"></a>

 Impeça que os usuários acessem dados e sistemas confidenciais diretamente em circunstâncias operacionais normais. Por exemplo, use um fluxo de trabalho de gerenciamento de alterações para gerenciar instâncias do Amazon Elastic Compute Cloud (Amazon EC2) usando ferramentas em vez de permitir acesso direto ou um host traga a sua própria licença. Isso pode ser obtido usando o [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), que usa [documentos de automação](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) que contêm etapas que você usa para realizar tarefas. Esses documentos podem ser armazenados no controle de origem, analisados por pares antes da execução e testados detalhadamente para minimizar os riscos em comparação com o acesso ao shell. Os usuários empresariais podem ter um painel em vez de acesso direto a um armazenamento de dados para executar consultas. Quando os pipelines de CI/CD não forem usados, determine quais controles e processos são necessários para fornecer adequadamente um mecanismo de acesso break-glass normalmente desabilitado. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>
+  Implemente mecanismos para manter as pessoas longe dos dados: os mecanismos incluem o uso de painéis, como o Quick, para exibir dados aos usuários em vez de consultar diretamente. 
  +  [Quick](https://aws.amazon.com/quicksight/) 
+  Automatize o gerenciamento de configuração: execute ações remotas, aplique e valide configurações seguras automaticamente usando uma ferramenta ou um serviço de gerenciamento de configuração. Evite usar hosts traga a sua própria licença ou acessar diretamente instâncias do EC2. 
  +  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
  +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
  +  [Pipeline de CI/CD do AWS CloudFormation para modelos na AWS](https://aws.amazon.com/quickstart/architecture/cicd-taskcat/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Whitepaper de detalhes criptográficos do AWS KMS](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 

 **Vídeos relacionados:** 
+  [How Encryption Works in AWS (Como a criptografia funciona no AWS Backup)](https://youtu.be/plv7PQZICCM) 
+  [Securing Your Block Storage on AWS (Como proteger o armazenamento em bloco na AWS)](https://youtu.be/Y1hE1Nkcxs8) 

# SEGURANÇA 9. Como proteger seus dados em trânsito?
<a name="sec-09"></a>

Proteja seus dados em trânsito implementando vários controles para reduzir o risco de acesso não autorizado ou perda.

**Topics**
+ [SEC09-BP01 Implementar o gerenciamento seguro de chaves e certificados](sec_protect_data_transit_key_cert_mgmt.md)
+ [SEC09-BP02 Aplicar a criptografia em trânsito](sec_protect_data_transit_encrypt.md)
+ [SEC09-BP03 Automatizar a detecção de acesso não intencional a dados](sec_protect_data_transit_auto_unintended_access.md)
+ [SEC09-BP04 Autenticar as comunicações de rede](sec_protect_data_transit_authentication.md)

# SEC09-BP01 Implementar o gerenciamento seguro de chaves e certificados
<a name="sec_protect_data_transit_key_cert_mgmt"></a>

 Os certificados Transport Layer Security (TLS) são usados para proteger as comunicações de rede e estabelecer a identidade de sites, recursos e workloads na internet, bem como em redes privadas. 

 **Resultado desejado:** Um sistema seguro de gerenciamento de certificados que pode provisionar, implantar, armazenar e renovar certificados em uma infraestrutura de chave pública (PKI). Um mecanismo seguro de gerenciamento de chaves e certificados evita que o material da chave privada do certificado seja divulgado e renova automaticamente o certificado periodicamente. Ele também se integra a outros serviços para fornecer comunicações de rede seguras e identidade para os recursos da máquina na workload. O material de chave nunca deve estar acessível a identidades humanas. 

 **Antipadrões comuns:** 
+  Executar etapas manuais durante os processos de implantação ou renovação de certificado. 
+  Não prestar a devida atenção à hierarquia da autoridade de certificação (CA) ao criar uma CA privada. 
+  Usar certificados autoassinados para recursos públicos. 

 **Benefícios de estabelecer esta prática recomendada: **
+  Simplificar o gerenciamento de certificados por meio de implantação e renovação automatizadas. 
+  Incentivar a criptografia de dados em trânsito usando certificados TLS. 
+  Aumentar a segurança e a auditabilidade das ações de certificação realizadas pela autoridade de certificação. 
+  Organizar as tarefas de gerenciamento em diferentes camadas da hierarquia da CA. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto

## Orientação para implementação
<a name="implementation-guidance"></a>

 As workloads modernas fazem uso extensivo de comunicações de rede criptografadas usando protocolos de PKI, como TLS. O gerenciamento de certificados PKI pode ser complexo, mas o provisionamento, a implantação e a renovação automatizados de certificados podem reduzir o atrito associado ao gerenciamento deles. 

 A AWS oferece dois serviços para gerenciar certificados de PKI de uso geral: [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) e [Autoridade de Certificação Privada da AWS (CA Privada da AWS)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html). O ACM é o principal serviço que os clientes usam para provisionar, gerenciar e implantar certificados para uso em workloads públicas e privadas da AWS. O ACM emite certificados usando o CA Privada da AWS e [integra-se](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) a muitos outros serviços gerenciados da AWS para fornecer certificados TLS seguros para workloads. 

 A CA Privada da AWS permite estabelecer a própria autoridade de certificação raiz ou subordinada e emitir certificados TLS por meio de uma API. É possível usar esses tipos de certificado em cenários em que você controla e gerencia a cadeia de confiança do lado do cliente da conexão TLS. Além dos casos de uso do TLS, a CA Privada da AWS pode ser usada para emitir certificados para pods do Kubernetes, atestados de produtos de dispositivos Matter, assinatura de código e outros casos de uso com um [modelo personalizado](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html). Você também pode usar [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) para fornecer credenciais do IAM temporárias para workloads on-premises que receberam certificados X.509 assinados pela CA privada. 

 Além do ACM e do CA Privada da AWS, o [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html) oferece suporte especializado para provisionar, gerenciar e implantar certificados de PKI em dispositivos de IoT. O AWS IoT Core fornece mecanismos especializados para [integração de dispositivos de IoT](https://docs.aws.amazon.com/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.html) à infraestrutura de chave pública em grande escala. 

**Considerações para estabelecer uma hierarquia de CA privada **

 Quando precisar estabelecer uma CA privada, é importante tomar cuidado especial para projetar adequadamente a hierarquia da CA com antecedência. É uma prática recomendada implantar cada nível de sua hierarquia de CA em Contas da AWS separadas ao criar uma hierarquia de CA privada. Essa etapa intencional reduz a área de superfície de cada nível na hierarquia da CA, simplificando a descoberta de anomalias nos dados de log do CloudTrail e reduzindo o escopo de acesso ou impacto se houver acesso não autorizado a uma das contas. A CA raiz deve residir em uma própria conta separada e deve ser usada somente para emitir um ou mais certificados de CA intermediários. 

 Depois, crie uma ou mais CAs intermediárias em contas separadas da conta da CA raiz para emitir certificados para usuários finais, dispositivos ou outras workloads. Por fim, emita certificados da CA raiz para as CAs intermediárias, que, por sua vez, emitirão certificados para os usuários finais ou dispositivos. Para obter mais informações sobre como planejar a implantação de CA e projetar a hierarquia de CA, incluindo planejamento de resiliência, replicação entre regiões, compartilhamento de CAs na organização e muito mais, consulte [Planning your CA Privada da AWS deployment](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html). 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Determine os serviços da AWS relevantes e necessários para seu caso de uso: 
   +  Muitos casos de uso podem aproveitar a infraestrutura de chave pública da AWS existente usando o [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html). O ACM pode ser usado para implantar certificados TLS para servidores web, balanceadores de carga ou outros usos para certificados publicamente confiáveis. 
   +  Considere [CA Privada da AWS](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) quando precisar estabelecer a própria hierarquia de autoridade de certificação privada ou precisar acessar certificados exportáveis. O ACM pode então ser usado para emitir [muitos tipos de certificados de entidade final](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html) usando a CA Privada da AWS. 
   +  Para casos de uso em que os certificados devem ser provisionados em grande escala para dispositivos incorporados de Internet das Coisas (IoT), pense no [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html). 

1.  Implemente a renovação automática do certificado sempre que possível: 
   +  Use [a renovação gerenciada pelo ACM](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) para certificados emitidos pelo ACM junto com serviços gerenciados da AWS integrados. 

1.  Estabeleça trilhas de auditoria e registro: 
   +  Habilite o [Logs do CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html) para monitorar o acesso às contas que têm autoridades de certificação. Considere configurar a validação da integridade do arquivo de log no CloudTrail para verificar a autenticidade dos dados de log. 
   +  Gere e revise periodicamente [relatórios de auditoria](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html) que listam os certificados que a CA privada emitiu ou revogou. Esses relatórios podem ser exportados para um bucket do S3. 
   +  Ao implantar uma CA privada, você também precisará estabelecer um bucket do S3 para armazenar a lista de revogação de certificados (CRL). Para obter orientação sobre como configurar esse bucket do S3 com base nos requisitos da workload, consulte [Planejar uma lista de revogação de certificados (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC02-BP02 Usar credenciais temporárias](sec_identities_unique.md) 
+ [SEC08-BP01 Implementar gerenciamento de chaves seguro](sec_protect_data_rest_key_mgmt.md)
+  [SEC09-BP04 Autenticar as comunicações de rede](sec_protect_data_transit_authentication.md) 

 **Documentos relacionados:** 
+  [How to host and manage an entire private certificate infrastructure in AWS](https://aws.amazon.com/blogs/security/how-to-host-and-manage-an-entire-private-certificate-infrastructure-in-aws/) 
+  [How to secure an enterprise scale ACM Private CA hierarchy for automotive and manufacturing](https://aws.amazon.com/blogs/security/how-to-secure-an-enterprise-scale-acm-private-ca-hierarchy-for-automotive-and-manufacturing/) 
+  [Práticas recomendadas de CA privada](https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html) 
+  [How to use AWS RAM to share your ACM Private CA cross-account](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/) 

 **Vídeos relacionados:** 
+  [Activating AWS Certificate Manager Private CA (workshop)](https://www.youtube.com/watch?v=XrrdyplT3PE) 

 **Exemplos relacionados:** 
+  [Workshop de CA privada](https://catalog.workshops.aws/certificatemanager/en-US/introduction) 
+  [IOT Device Management Workshop](https://iot-device-management.workshop.aws/en/) (incluindo provisionamento de dispositivos) 

 **Ferramentas relacionadas:** 
+  [Plug-in para o gerenciador de certificados do Kubernetes para usar a CA Privada da AWS](https://github.com/cert-manager/aws-privateca-issuer) 

# SEC09-BP02 Aplicar a criptografia em trânsito
<a name="sec_protect_data_transit_encrypt"></a>

Aplique os requisitos de criptografia definidos com base em políticas, obrigações regulatórias e padrões da organização para cumprir os requisitos organizacionais, legais e de conformidade. Utilize somente protocolos com criptografia ao transmitir dados sigilosos para fora da sua nuvem privada virtual (VPC). A criptografia ajuda a manter a confidencialidade dos dados mesmo quando os dados passam por redes não confiáveis.

 **Resultado desejado:** todos os dados devem ser criptografados em trânsito com pacotes de criptografia e protocolos TLS seguros. O tráfego de rede entre seus recursos e a Internet deve ser criptografado para reduzir o acesso não autorizado aos dados. O tráfego de rede exclusivamente em seu ambiente interno da AWS deve ser criptografado com TLS sempre que possível. A rede interna da AWS é criptografada por padrão e o tráfego de rede em uma VPC não pode ser adulterado nem interceptado a menos que uma parte não autorizada tenha obtido acesso ao recurso que esteja gerando o tráfego (como instâncias do Amazon EC2 e contêineres do Amazon ECS). Considere proteger o tráfego de rede para rede com uma rede privada virtual (VPN) IPsec. 

 **Antipadrões comuns:** 
+  Utilizar versões obsoletas de SSL, TLS e componentes do pacote de criptografia (por exemplo, SSL v3.0, chaves RSA de 1024 bits e criptografia RC4). 
+  Permitir tráfego não criptografado (HTTP) para ou de recursos voltados para o público. 
+  Não monitorar e substituir certificados X.509 antes da validade. 
+  Utilizar certificados X.509 autoassinados para TLS. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Os serviços da AWS fornecem endpoints HTTPS usando TLS para comunicação, fornecendo criptografia em trânsito quando se comunicam com as APIs da AWS. Protocolos não seguros, como HTTP, podem ser auditados e bloqueados em uma VPC por meio do uso de grupos de segurança. Solicitações HTTP também podem ser [redirecionadas automaticamente para HTTPS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) no Amazon CloudFront ou em um [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions). Você tem controle total sobre seus recursos de computação para implementar a criptografia em trânsito em seus serviços. Além disso, você pode usar a conectividade VPN em sua VPC a partir de uma rede externa ou [AWS Direct Connect](https://aws.amazon.com/directconnect/) para facilitar a criptografia do tráfego. Verifique se os seus clientes estão fazendo chamadas para APIs da AWS utilizando pelo menos TLS 1.2, pois a [AWS tornará obsoleto o uso de TLS 1.0 e 1.1 em junho de 2023](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/). Soluções de terceiros estão disponíveis no AWS Marketplace, caso você tenha requisitos especiais. 

 **Etapas da implementação** 
+  **Aplicar a criptografia em trânsito:** os requisitos de criptografia definidos devem se basear nos mais recentes padrões e práticas recomendadas e permitir apenas protocolos seguros. Por exemplo, configure apenas um grupo de segurança para permitir o protocolo HTTPS a um Application Load Balancer ou instância do Amazon EC2. 
+  **Configurar protocolos seguros em serviços de borda:** [configure o HTTPS com Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html) e utilize um [perfil de segurança apropriado para seu procedimento de segurança e caso de uso](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-supported-ciphers). 
+  **Utilizar uma [VPN para conectividade externa](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html):** considere usar uma VPN IPsec para proteger conexões ponto a ponto ou rede a rede para fornecer privacidade e integridade dos dados. 
+  **Configurar protocolos seguros em balanceadores de carga:** selecione uma política de segurança que ofereça os pacotes de criptografia mais fortes compatíveis com os clientes que se conectarão ao receptor. [Criar um receptor de HTTPS para seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html). 
+  **Configurar protocolos seguros no Amazon Redshift:** configure o cluster para exigir uma [conexão Secure Socket Layer (SSL) ou Transport Layer Security (TLS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html). 
+  **Configurar protocolos seguros:** leia a documentação do serviço da AWS para determinar os recursos de criptografia em trânsito. 
+  **Configurar o acesso seguro ao fazer upload para buckets do Amazon S3:** utilize controles de política de bucket do Amazon S3 para [implementar acesso seguro](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) aos dados. 
+  **Considerar o uso do [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/):** o ACM permite fornecer, gerenciar e implantar certificados TLS públicos para uso com serviços da AWS. 
+  **Considerar o uso do [Autoridade de Certificação Privada da AWS](https://aws.amazon.com/private-ca/) para necessidades de PKI privada:** o CA Privada da AWS permite criar hierarquias de autoridade de certificado privada (CA) para emitir certificados X.509 entidade final que podem ser usados para criar canais de TLS criptografados. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Documentação da AWS](https://docs.aws.amazon.com/index.html)
+ [ Utilizar HTTPS com o CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html)
+ [ Conectar sua VPC a redes remotas usando a AWS Virtual Private Network](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html)
+ [ Criar um receptor de HTTPS para seu Application Load Balancer ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)
+ [ Tutorial: configurar o SSL/TLS no Amazon Linux 2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html)
+ [Usar SSL/TLS para criptografar uma conexão com uma instância de banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)
+ [ Configurar as opções de segurança para conexões ](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html)

# SEC09-BP03 Automatizar a detecção de acesso não intencional a dados
<a name="sec_protect_data_transit_auto_unintended_access"></a>

 Use ferramentas como o Amazon GuardDuty para detectar automaticamente atividades suspeitas ou tentativas de mover dados para fora dos limites definidos. Por exemplo, o GuardDuty pode detectar atividade de leitura do Amazon Simple Storage Service (Amazon S3) que é incomum com a descoberta [Exfiltration:S3/AnomalousBehavior](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-s3.html#exfiltration-s3-objectreadunusual). Além do GuardDuty, [Logs de fluxo da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html), que capturam informações de tráfego de rede, podem ser usados com o Amazon EventBridge para acionar a detecção de conexões anormais, bem-sucedidas e recusadas. [Amazon S3 Access Analyzer](http://aws.amazon.com/blogs/storage/protect-amazon-s3-buckets-using-access-analyzer-for-s3) pode ajudar a avaliar quais dados podem ser acessados por quem nos buckets do Amazon S3. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Automatizar a detecção de acesso não intencional a dados: use uma ferramenta ou um mecanismo de identificação para detectar automaticamente tentativas de mover dados fora dos limites definidos; por exemplo, para descobrir um sistema de banco de dados que esteja copiando dados para um host desconhecido. 
  + [ Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 
+  Considerar o Amazon Macie: o Amazon Macie é um serviço de privacidade e segurança de dados totalmente gerenciado que usa machine learning e correspondência de padrões para descobrir e proteger seus dados sigilosos na AWS. 
  + [ Amazon Macie ](https://aws.amazon.com/macie/)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 
+ [ Amazon Macie ](https://aws.amazon.com/macie/)

# SEC09-BP04 Autenticar as comunicações de rede
<a name="sec_protect_data_transit_authentication"></a>

 Verifique a identidade das comunicações usando protocolos que oferecem suporte à autenticação, como Transport Layer Security (TLS) ou IPsec. 

 Projete a workload para usar protocolos de rede seguros e autenticados sempre que for feita uma comunicação entre serviços, aplicações ou usuários. O uso de protocolos de rede compatíveis com a autenticação e a autorização fornece maior controle sobre os fluxos de rede e reduz o impacto do acesso não autorizado. 

 **Resultado desejado:** uma workload com fluxos de tráfego bem definidos do plano de dados e do ambiente de gerenciamento entre os serviços. Os fluxos de tráfego usam protocolos de rede autenticados e criptografados quando tecnicamente viáveis. 

 **Antipadrões comuns:** 
+  Fluxos de tráfego não criptografados ou não autenticados na workload. 
+  Reutilizar credenciais de autenticação entre vários usuários ou entidades. 
+  Confiar apenas nos controles de rede como um mecanismo de controle de acesso. 
+  Criar um mecanismo de autenticação personalizado em vez de depender de mecanismos de autenticação padrão do setor. 
+  Fluxos de tráfego excessivamente permissivos entre componentes de serviço ou outros recursos na VPC. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Limita o escopo do impacto do acesso não autorizado a uma parte da workload. 
+  Fornece um nível mais alto de garantia de que as ações são executadas somente por entidades autenticadas. 
+  Melhora o desacoplamento de serviços definindo e aplicando claramente as interfaces de transferência de dados pretendidas. 
+  Melhora o monitoramento, o log e a resposta a incidentes por meio da atribuição de solicitações e interfaces de comunicação bem definidas. 
+  Oferece defesa profunda para as workloads combinando controles de rede com controles de autenticação e de autorização. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Os padrões de tráfego de rede da workload podem ser caracterizados em duas categorias: 
+  O *tráfego leste-oeste* representa fluxos de tráfego entre serviços que compõem uma workload. 
+  O *tráfego norte-sul* representa fluxos de tráfego entre a workload e os consumidores. 

 Embora seja uma prática comum criptografar o tráfego norte-sul, é menos comum proteger o tráfego leste-oeste usando protocolos autenticados. As práticas modernas de segurança recomendam que o design da rede por si só não conceda um relacionamento confiável entre duas entidades. Quando dois serviços puderem residir dentro de um limite de rede comum, criptografar, autenticar e autorizar as comunicações ainda são práticas recomendadas entre esses serviços. 

 Como exemplo, as APIs de serviços da AWS usam o protocolo de assinatura do [Signature Version 4 (SigV4) da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) para autenticar o chamador, independentemente da rede de origem da solicitação. Essa autenticação garante que as APIs da AWS possam verificar a identidade que solicitou a ação e que essa identidade possa ser combinada com políticas para tomar uma decisão de autorização a fim de determinar se a ação deve ser permitida ou não. 

 Serviços, como o [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/access-management-overview.html) e o [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) permitem usar o mesmo protocolo de assinatura SigV4 para adicionar autenticação e autorização ao tráfego leste-oeste em suas próprias workloads. Se os recursos fora do ambiente da AWS precisarem se comunicar com os serviços que exigem autenticação e autorização baseadas em SigV4, você poderá usar o [AWS Identity and Access Management (IAM) Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) no recurso que não é da AWS para adquirir credenciais temporárias da AWS. Essas credenciais podem ser usadas para assinar solicitações para serviços que usam o SigV4 para autorizar o acesso. 

 Outro mecanismo comum para autenticar o tráfego leste-oeste é a autenticação mútua TLS (mTLS). Muitas aplicações da Internet das Coisas (IoT), aplicações business to business e microsserviços usam o mTLS para validar a identidade de ambos os lados de uma comunicação TLS por meio do uso de certificados X.509 do lado do cliente e do servidor. Esses certificados podem ser emitidos por Autoridade de Certificação Privada da AWS (CA Privada da AWS). É possível usar serviços como o [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) e o [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html) para fornecer autenticação mTLS para comunicação entre workloads ou dentro da workload. Embora o mTLS forneça informações de autenticação aos dois lados de uma comunicação TLS, ele não fornece um mecanismo de autorização. 

 Por fim, o OAuth 2.0 e o OpenID Connect (OIDC) são dois protocolos normalmente usados para controlar o acesso aos serviços pelos usuários, mas agora também estão se tornando populares para o tráfego entre serviços. O API Gateway fornece um [autorizador JSON Web Token (JWT)](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html), que permite que as workloads restrinjam o acesso às rotas de API usando JWTs emitidos por provedores de identidades OIDC ou OAuth 2.0. Os escopos do OAuth2 podem ser usados como uma fonte para decisões básicas de autorização, mas as verificações de autorização ainda precisam ser implementadas na camada da aplicação, e os escopos do OAuth2 por si sós não atendem a necessidades de autorização mais complexas. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Definir e documentar os fluxos de rede da workload:** a primeira etapa na implementação de uma estratégia de defesa profunda é definir os fluxos de tráfego da workload. 
  +  Crie um diagrama de fluxo de dados que defina claramente como os dados são transmitidos entre os diferentes serviços que compõem a workload. Esse diagrama é a primeira etapa para aplicar esses fluxos por meio de canais de rede autenticados. 
  +  Instrumente a workload nas fases de desenvolvimento e testes para validar se o diagrama de fluxo de dados reflete com precisão o comportamento da workload em tempo de execução. 
  +  Um diagrama de fluxo de dados também pode ser útil ao realizar um exercício de modelagem de ameaças, conforme descrito em [SEC01-BP07 Identificar ameaças e priorizar mitigações com o uso de um modelo de ameaça](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html). 
+  **Estabeleça controles de rede:** considere os recursos da AWS para estabelecer controles de rede alinhados aos fluxos de dados. Embora os limites da rede não devam ser o único controle de segurança, eles fornecem uma camada na estratégia de defesa profunda para proteger a workload. 
  +  Use [grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html) para estabelecer, definir e restringir fluxos de dados entre recursos. 
  +  Considere usar o [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) para se comunicar com os serviços da AWS e de terceiros que são compatíveis com o AWS PrivateLink. Os dados enviados por meio de um endpoint da interface do AWS PrivateLink permanecem na estrutura da rede da AWS e não atravessam a internet pública. 
+  **Implementar autenticação e autorização entre os serviços na workload:** escolha o conjunto de serviços da AWS mais apropriado para fornecer fluxos de tráfego autenticados e criptografados na workload. 
  +  Considere o [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) para proteger a comunicação entre serviços. O VPC Lattice pode usar a [autenticação do SigV4 combinada com políticas de autenticação](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html) para controlar o acesso entre serviços. 
  +  Para comunicação entre serviços usando mTLS, considere o [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) ou o [App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html). O [CA Privada da AWS](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) pode ser usado para estabelecer uma hierarquia de CA privada capaz de emitir certificados para uso com o mTLS. 
  +  Ao fazer a integração com serviços que usam OAuth 2.0 ou OIDC, considere o [API Gateway usando o autorizador JWT](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html). 
  +  Para comunicação entre a workload e dispositivos de IoT, considere o [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html), que fornece várias opções para criptografia e autenticação de tráfego de rede. 
+  **Monitorar o acesso não autorizado:** monitore continuamente os canais de comunicação não intencionais, entidades principais não autorizadas que tentam acessar recursos protegidos e outros padrões de acesso inadequados. 
  +  Se estiver usando o VPC Lattice para gerenciar o acesso aos serviços, considere ativar e monitorar os [logs de acesso do VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html). Esses logs de acesso incluem informações sobre a entidade solicitante, informações de rede que incluem a VPC de origem e de destino e os metadados da solicitação. 
  +  Considere a ativação dos [Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) para capturar metadados nos fluxos de rede e analisar se há anomalias periodicamente. 
  +  Consulte o [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) e a seção [Resposta a incidentes ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) do Pilar Segurança: AWS Well-Architected Framework para obter mais orientações sobre planejamento, simulação e resposta a incidentes de segurança. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [SEC03-BP07 Analisar o acesso público e entre contas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC02-BP02 Usar credenciais temporárias](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC01-BP07 Identificar ameaças e priorizar mitigações com o uso de um modelo de ameaça](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)

 **Documentos relacionados:** 
+ [ Evaluating access control methods to secure Amazon API Gateway APIs ](https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/)
+ [ Configurar a autenticação TLS mútua para uma API REST ](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)
+ [ How to secure API Gateway HTTP endpoints with JWT authorizer ](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)
+ [ Authorizing direct calls to AWS services using AWS IoT Core credential provider ](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)
+ [ Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)

 **Vídeos relacionados:** 
+ [AWS re:invent 2022: Introducing VPC Lattice ](https://www.youtube.com/watch?v=fRjD1JI0H5w)
+ [AWS re:invent 2020: Serverless API authentication for HTTP APIs on AWS](https://www.youtube.com/watch?v=AW4kvUkUKZ0)

 **Exemplos relacionados:** 
+ [ Workshop do Amazon VPC Lattice ](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [Workshop Zero-Trust Episode 1 – The Phantom Service Perimeter](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)

# Resposta a incidentes
<a name="a-incident-response"></a>

**Topics**
+ [SEGURANÇA 10. Como prever, responder e se recuperar de incidentes?](sec-10.md)

# SEGURANÇA 10. Como prever, responder e se recuperar de incidentes?
<a name="sec-10"></a>

 Mesmo com controles preventivos e de detecção consolidados, sua organização deve implementar processos para responder e reduzir o impacto potencial de incidentes de segurança. Sua preparação afeta muito a capacidade das equipes operarem efetivamente durante um incidente, isolarem, conterem e analisarem problemas e restaurarem as operações para um estado adequado conhecido. Implementar as ferramentas e o acesso antes de um incidente de segurança e praticar rotineiramente dias de jogos para validar a resposta a incidentes ajuda a garantir que você possa se recuperar enquanto minimiza interrupções empresariais. 

**Topics**
+ [SEC10-BP01 Identify key personnel and external resources](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 Desenvolver planos de gerenciamento de incidentes](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 Prepare recursos forenses](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 Desenvolva e teste manuais de resposta a incidentes de segurança](sec_incident_response_playbooks.md)
+ [SEC10-BP05 Acesso pré-provisionado](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 Pré-implantação de ferramentas](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 Execute simulações](sec_incident_response_run_game_days.md)
+ [SEC10-BP08 Estabeleça uma estrutura para aprender com os incidentes](sec_incident_response_establish_incident_framework.md)

# SEC10-BP01 Identify key personnel and external resources
<a name="sec_incident_response_identify_personnel"></a>

 Identifique o pessoal, as obrigações legais e os recursos internos e externos que ajudariam sua organização a responder a um incidente. 

Para definir sua abordagem de resposta a incidentes na nuvem, com a participação de outras equipes (como consultoria jurídica, liderança, partes interessadas de negócios, serviços do AWS Support e outras), você deve identificar as principais partes interessadas, pessoal e contatos relevantes. Para reduzir a dependência e diminuir o tempo de resposta, certifique-se de que sua equipe, equipes de segurança especializadas e respondentes sejam instruídos sobre os serviços que você usa e tenham a oportunidade de praticar.

É recomendável identificar parceiros externos de segurança da AWS que possam fornecer experiência externa e uma perspectiva diferente para aumentar seus recursos de resposta. Os parceiros de segurança confiáveis podem ajudá-lo a identificar possíveis riscos ou ameaças com os quais você talvez não esteja familiarizado.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>
+  **Identificar o pessoal-chave da organização:** Mantenha uma lista de contatos da sua organização que você precisaria acionar para responder e recuperar-se de um incidente. 
+  **Identificar parceiros externos:** Entre em contato com parceiros externos, se necessário, que possam ajudá-lo a responder e se recuperar de um incidente. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Incident Response Guide (Guia de resposta a incidentes da AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **Vídeos relacionados:** 
+  [Prepare for and respond to security incidents in your AWS environment (Prepare-se e responda a incidentes de segurança no ambiente da AWS) ](https://youtu.be/8uiO0Z5meCs)

 **Exemplos relacionados:** 

# SEC10-BP02 Desenvolver planos de gerenciamento de incidentes
<a name="sec_incident_response_develop_management_plans"></a>

O primeiro documento a ser desenvolvido para resposta a incidentes é o plano de resposta a incidentes. O plano de resposta a incidentes foi projetado para ser a base de seu programa e estratégia de resposta a incidentes. 

 **Benefícios de estabelecer esta prática recomendada:** O desenvolvimento de processos de resposta a incidentes completos e claramente definidos é fundamental para um programa de resposta a incidentes bem-sucedido e escalável. Quando ocorre um evento de segurança, etapas e fluxos de trabalho claros poderão ajudar você a responder em tempo hábil. Talvez você já tenha processos de resposta a incidentes existentes. Independentemente do seu estado atual, é importante atualizar, repetir e testar seus processos de resposta a incidentes regularmente. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

Um plano de gerenciamento de incidentes é fundamental para responder, mitigar e se recuperar de possíveis impactos de incidentes de segurança. Um plano de gerenciamento de incidentes é um processo estruturado de identificação, correção e resposta em tempo hábil a incidentes de segurança.

 A nuvem tem muitos dos mesmos requisitos e perfis operacionais encontrados em um ambiente on-premises. Ao criar um plano de gerenciamento de incidentes, é importante definir estratégias de resposta e recuperação que se alinhem melhor aos seus resultados empresariais e requisitos de conformidade. Por exemplo, se você opera workloads na AWS em conformidade com o FedRAMP nos Estados Unidos, é útil aderir ao [Guia de tratamento de segurança de computadores NIST SP 800-61](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf). Da mesma forma, ao operar workloads com informações de identificação pessoal (PII) da Europa, considere cenários como a maneira como você deve se proteger e responder a incidentes relacionados à residência de dados, conforme exigido pela [Regulamentação Geral de Proteção de Dados (GDPR) da UE](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en). 

 Ao criar um plano de gerenciamento de incidentes para suas workloads na AWS, comece com o [Modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) , para elaborar uma abordagem de defesa profunda em relação à resposta a incidentes. Nesse modelo, a AWS gerencia a segurança da nuvem, e você é responsável pela segurança na nuvem. Isso significa que você mantém o controle e é responsável pelos controles de segurança que escolhe implementar. O [AWS Security Incident Response Guide (Guia de resposta a incidentes de segurança da AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) detalha os conceitos e as orientações básicas para criar um plano de gerenciamento de incidentes centrado na nuvem.

 Um plano de gerenciamento de incidentes eficaz deve ser continuamente iterado e permanecer atualizado com relação às suas metas de operações de nuvem. Considere o uso dos planos de implementação detalhados abaixo, à medida que cria e evolui seu plano de gerenciamento de incidentes. 

## Etapas da implementação
<a name="implementation-steps"></a>

 **Defina funções e responsabilidades** 

 Lidar com eventos de segurança exige disciplina interorganizacional e uma inclinação para a ação. Em sua estrutura organizacional, deve haver muitas pessoas responsáveis, atribuídas, consultadas ou mantidas informadas durante um incidente, como representantes de recursos humanos (RH), da equipe executiva e do setor jurídico. Considere essas funções e responsabilidades e se algum terceiro deve estar envolvido. Observe que muitas regiões têm leis locais que regem o que deve e o que não deve ser feito. Embora possa parecer burocrático criar um grafo de pessoas responsáveis, atribuídas, consultadas e informadas (RACI) para seus planos de resposta de segurança, isso facilita a comunicação rápida e direta e descreve claramente a liderança em diferentes estágios do evento. 

 Durante um incidente, incluir os proprietários e os desenvolvedores de aplicações e recursos afetados é fundamental porque eles são especialistas no assunto (PMEs) que podem fornecer informações e contexto para ajudar a medir o impacto. Pratique e construa relacionamentos com os desenvolvedores e os proprietários de aplicações antes de confiar na experiência deles para responder a incidentes. Proprietários de aplicações ou PMEs, como administradores ou engenheiros de nuvem, podem precisar agir em situações em que o ambiente não seja familiar ou tenha complexidade, ou em que os respondentes não tenham acesso. 

 Por fim, parceiros confiáveis podem estar envolvidos na investigação ou na resposta, pois podem oferecer experiência adicional e um controle valioso. Se você não tiver essas habilidades em sua própria equipe, contrate uma parte externa para obter assistência. 

 **Entender as equipes de resposta e o suporte da AWS** 
+  **AWS Support** 
  +  [O Suporte](https://aws.amazon.com/premiumsupport/) oferece uma variedade de planos que concedem acesso a ferramentas e conhecimentos que apoiam o êxito e a saúde operacional de suas soluções da AWS. Se precisar de suporte técnico e mais recursos para ajudar a planejar, implantar e otimizar seu ambiente da AWS, selecione um plano de suporte mais adequado ao seu caso de uso da AWS. 
  +  Considere o [Support Center](https://console.aws.amazon.com/support) entre Console de gerenciamento da AWS (é necessário fazer login) como ponto central de contato para obter suporte para problemas que afetam seus recursos da AWS. O acesso ao Suporte é controlado pelo AWS Identity and Access Management. Para ter mais informações sobre como obter acesso aos recursos da Suporte, consulte [Conceitos básicos do Suporte](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support). 
+  **Equipe de Resposta a Incidentes de Clientes (CIRT) da AWS** 
  +  A Equipe de Resposta a Incidentes de Clientes (CIRT) da AWS é uma equipe global da AWS especializada 24 horas por dia, 7 dias por semana, que presta assistência aos clientes durante eventos de segurança ativos do cliente do [Modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/). 
  +  Ao apoiar você, a AWS CIRT presta assistência na triagem e na recuperação de um evento de segurança ativo na AWS. Eles podem ajudar na análise da causa raiz por meio do uso de logs de serviço da AWS e fornecer recomendações para recuperação. Eles também podem fornecer recomendações de segurança e práticas recomendadas para ajudar você a evitar eventos de segurança no futuro. 
  +  Os clientes da AWS podem contratar a AWS CIRT por meio de um [caso do Suporte](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html). 
+  **Suporte de resposta a DDoS** 
  +  A AWS oferece o [AWS Shield](https://aws.amazon.com/shield/), que fornece um serviço gerenciado de proteção distribuída de negação de serviço (DDoS) que protege as aplicações web em execução na AWS. O Shield oferece detecção contínua e mitigações automáticas em linha que podem minimizar o tempo de inatividade e a latência da aplicação, portanto, não há necessidade de contratar o Suporte para se beneficiar da proteção contra DDoS. Existem dois níveis de Shield: AWS Shield Standard e AWS Shield Advanced. Para saber mais sobre as diferenças entre esses dois níveis, consulte a [documentação de recursos do Shield](https://aws.amazon.com/shield/features/). 
+  **AWS Managed Services (AMS)** 
  +  [O AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) oferece gerenciamento contínuo de sua infraestrutura da AWS para que você possa se concentrar em suas aplicações. Ao implementar as práticas recomendadas para manter sua infraestrutura, o AMS ajuda a reduzir sua sobrecarga operacional e os riscos. O AMS automatiza atividades comuns, como solicitações de mudança, monitoramento, gerenciamento de patches, serviços de segurança e backup, e fornece serviços de ciclo de vida completo para provisionar, executar e oferecer compatibilidade com sua infraestrutura. 
  +  O AMS assume a responsabilidade de implantar um pacote de controles de detecção de segurança e fornece uma primeira linha de resposta aos alertas 24 horas por dia, 7 dias por semana. Quando um alerta é iniciado, o AMS segue um conjunto padrão de guias e manuais automatizados para verificar uma resposta consistente. Esses guias são compartilhados com os clientes do AMS durante a integração para que eles possam desenvolver e coordenar uma resposta com o AMS. 

 **Desenvolva o plano de resposta a incidentes** 

 O plano de resposta a incidentes foi projetado para ser a base de seu programa e estratégia de resposta a incidentes. O plano de resposta a incidentes deve estar em um documento formal. Um plano de resposta a incidentes geralmente inclui as seguintes seções: 
+  **Uma visão geral da equipe de resposta a incidentes:** Descreve as metas e as funções da equipe de resposta a incidentes. 
+  **Funções e responsabilidades:** Lista as partes interessadas na resposta a incidentes e detalha suas funções quando ocorre um incidente. 
+  **Um plano de comunicação:** Detalha as informações de contato e como você se comunica durante um incidente. 
+  **Métodos de comunicação de backup:** É prática recomendada ter a comunicação fora de banda como backup para a comunicação de incidentes. Um exemplo de aplicação que fornece um canal seguro de comunicação fora de banda é AWS Wickr. 
+  **Fases da resposta a incidentes e ações a serem realizadas:** Enumera as fases da resposta a incidentes (por exemplo, detectar, analisar, erradicar, conter e recuperar), incluindo ações de alto nível a serem realizadas nessas fases. 
+  **Definições de severidade e priorização do incidente:** Detalha como classificar a severidade de um incidente, como priorizar o incidente e, depois, como as definições de severidade afetam os procedimentos de escalonamento. 

 Embora essas seções sejam comuns em empresas de diferentes tamanhos e setores, o plano de resposta a incidentes de cada organização é único. Você precisa criar um plano de resposta a incidentes que funcione melhor para a organização. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC04 (Como você detecta e investiga eventos de segurança?)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) 

 **Documentos relacionados:** 
+  [AWS Security Incident Response Guide (Guia de resposta a incidentes de segurança da AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [ NIST: Guia de tratamento de incidentes de segurança de computadores ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)

# SEC10-BP03 Prepare recursos forenses
<a name="sec_incident_response_prepare_forensic"></a>

Antes de um incidente de segurança, considere o desenvolvimento de recursos forenses para apoiar as investigações de eventos de segurança. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

 Os conceitos da análise forense on-premises tradicional se aplicam à AWS. Para obter informações importantes para começar a desenvolver recursos forenses na Nuvem AWS, consulte [Forensic investigation environment strategies in the Nuvem AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/). 

 Depois de configurar o ambiente e a estrutura da Conta da AWS para análise forense, defina as tecnologias necessárias para executar com eficácia metodologias forenses sólidas nas quatro fases: 
+  **Coleta:** Colete logs relevantes da AWS, como logs do AWS CloudTrail, do AWS Config, logs de fluxo da VPC e log em nível de host. Colete snapshots, backups e despejos de memória dos recursos afetados da AWS, quando disponíveis. 
+  **Exame:** Examine os dados coletados extraindo e avaliando as informações relevantes. 
+  **Análises:** Analise os dados coletados para entender o incidente e tirar conclusões dele. 
+  **Relatórios:** Apresente as informações resultantes da fase de análise. 

## Etapas da implementação
<a name="implementation-steps"></a>

 **Prepare o ambiente forense** 

 [AWS Organizations](https://aws.amazon.com/organizations/) ajuda a gerenciar e reger centralmente um ambiente da AWS à medida que você expande e escala os recursos da AWS. Uma organização da AWS consolida suas Contas da AWS para que você possa administrá-las como uma única unidade. Você pode usar unidades organizacionais (UOs) para agrupar contas e administrá-las como uma única unidade. 

 Para resposta a incidentes, é útil ter uma estrutura da Conta da AWS compatível com as funções de resposta a incidentes, que inclui uma *UO de segurança* e uma *UO forense*. Dentro da OU de segurança, você deve ter contas para: 
+  **Arquivamento de logs:** Agregue logs em uma Conta da AWS de arquivamento de logs com permissões limitadas. 
+  **Ferramentas de segurança:** Centralize os serviços de segurança em uma Conta da AWS de ferramenta de segurança. Essa conta opera como administrador delegado dos serviços de segurança. 

 Dentro da UO forense, você tem a opção de implementar uma única conta ou contas forenses para cada região em que opera, dependendo da que funciona melhor para sua empresa e modelo operacional. Se você criar uma conta forense por região, poderá bloquear a criação de recursos da AWS fora dessa região e reduzir o risco de os recursos serem copiados para uma região não pretendida. Por exemplo, se você opera apenas em US East (N. Virginia) Region (`us-east-1`) e US West (Oregon) (`us-west-2`), então você teria duas contas na UO forense: uma para `us-east-1` e uma para `us-west-2`. 

 Você pode criar uma Conta da AWS de análise forense para várias regiões. Você deve ter cuidado ao copiar recursos da AWS para essa conta para verificar se está de acordo com seus requisitos de soberania de dados. Como é preciso tempo para provisionar novas contas, é imperativo criar e instrumentar as contas forenses bem antes de um incidente, para que os respondentes possam estar preparados para usá-las de forma eficaz em suas respostas. 

 O diagrama a seguir exibe um exemplo de estrutura de contas, incluindo uma UO forense com contas forenses por região: 

![\[Diagrama de fluxo mostrando uma estrutura de contas por região para resposta a incidentes, bifurcada em uma UO forense e de segurança.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/region-account-structure.png)


 **Capture backups e snapshots** 

 Configurar backups dos principais sistemas e bancos de dados é essencial para a recuperação de um incidente de segurança e para fins forenses. Com os backups em vigor, você pode restaurar seus sistemas ao estado seguro anterior. Na AWS, você pode criar snapshots de vários recursos. Os snapshots fornecem backups pontuais desses recursos. Há muitos serviços da AWS que podem ajudar em backup e recuperação. Para obter detalhes sobre esses serviços e abordagens para backup e recuperação, consulte [Backup and Recovery Prescriptive Guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) e [Use backups to recover from security incidents](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/). 

 Especialmente quando se trata de situações como ransomware, é fundamental que os backups estejam bem protegidos. Para obter orientações sobre como proteger os backups, consulte [Top 10 security best practices for securing backups in AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/). Além de proteger os backups, você deve testar regularmente seus processos de backup e restauração para verificar se a tecnologia e os processos implementados funcionam conforme o esperado. 

 **Automatize a análise forense** 

 Durante um evento de segurança, sua equipe de resposta a incidentes deve ser capaz de coletar e analisar evidências rapidamente, mantendo a precisão durante o período em torno do evento (como capturar registros relacionados a um evento ou recurso específico ou coletar o despejo de memória de uma instância do Amazon EC2). É desafiador e demorado para a equipe de resposta a incidentes coletar manualmente as evidências relevantes, especialmente em um grande número de instâncias e contas. Além disso, a coleta manual pode estar sujeita a erros humanos. Por esses motivos, você deve desenvolver e implementar a automação para perícia o máximo possível. 

 A AWS oferece vários recursos de automação para análise forense, que estão listados na seção de recursos a seguir. Esses recursos são exemplos de padrões forenses que desenvolvemos e que os clientes implementaram. Embora possam ser uma arquitetura de referência útil para começar, considere modificá-las ou criar padrões de automação forense com base em seu ambiente, requisitos, ferramentas e processos forenses. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Security Incident Response Guide - Develop Forensics Capabilities ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/develop-forensics-capabilities.html)
+ [AWS Security Incident Response Guide - Forensics Resources ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-b-incident-response-resources.html#forensic-resources)
+ [Forensic investigation environment strategies in the Nuvem AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)
+  [How to automate forensic disk collection in AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) 
+ [AWS Prescriptive Guidance - Automate incident response and forensics ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html)

 **Vídeos relacionados:** 
+ [ Automatização de resposta a incidentes e forense ](https://www.youtube.com/watch?v=f_EcwmmXkXk)

 **Exemplos relacionados:** 
+ [ Automated Incident Response and Forensics Framework (Estrutura forense e de resposta automatizada a incidentes) ](https://github.com/awslabs/aws-automated-incident-response-and-forensics)
+ [ Automated Forensics Orchestrator for Amazon EC2 ](https://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/welcome.html)

# SEC10-BP04 Desenvolva e teste manuais de resposta a incidentes de segurança
<a name="sec_incident_response_playbooks"></a>

 Uma parte fundamental da preparação de seus processos de resposta a incidentes é desenvolver manuais. Os manuais de resposta a incidentes fornecem uma série de orientações prescritivas e etapas a serem seguidas quando ocorre um evento de segurança. Ter uma estrutura e etapas claras simplifica a resposta e reduz a probabilidade de erro humano. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Os manuais devem ser criados para cenários de incidentes, como: 
+  **Incidentes esperados**: os manuais devem ser criados para os incidentes previstos. Isso inclui ameaças como negação de serviço (DoS), ransomware e comprometimento de credenciais. 
+  **Descobertas ou alertas de segurança conhecidos**: os manuais devem ser criados para descobertas e alertas de segurança conhecidos, como descobertas do GuardDuty. Você pode receber uma descoberta do GuardDuty e pensar: “E agora?” Para evitar que você trate incorretamente ou ignore uma descoberta do GuardDuty, crie um manual para cada possível descoberta do GuardDuty. Alguns detalhes e orientações sobre a correção podem ser encontrados na [documentação do GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html). É importante notar que o GuardDuty não está habilitado por padrão e tem um custo. Para obter mais detalhes sobre o GuardDuty, consulte [Appendix A: Cloud capability definitions - Visibility and alerting](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/visibility-and-alerting.html). 

 Os manuais devem conter etapas técnicas a serem concluídas por um analista de segurança para investigar e responder adequadamente a um possível incidente de segurança. 

### Etapas da implementação
<a name="implementation-steps"></a>

 Os itens a serem incluídos em um manual incluem: 
+  **Visão geral do manual**: qual cenário de risco ou incidente esse manual aborda? Qual é o objetivo do manual? 
+  **Pré-requisitos**: quais logs, mecanismos de detecção e ferramentas automatizadas são necessários para esse cenário de incidente? Qual é a notificação esperada? 
+  **Informações de comunicação e escalonamento**: quem está envolvido e quais são suas informações de contato? Quais são as responsabilidades de cada parte interessada? 
+  **Etapas de resposta**: em todas as fases da resposta a incidentes, quais etapas táticas devem ser seguidas? Quais consultas um analista deve executar? Qual código deve ser executado para alcançar o resultado desejado? 
  +  **Detectar**: como o incidente será detectado? 
  +  **Análise**: como o escopo do impacto será determinado? 
  +  **Contêm**: como o incidente será isolado para limitar o escopo? 
  +  **Erradicar**: como a ameaça será removida do ambiente? 
  +  **Recuperar**: como o sistema ou o recurso afetado voltará à produção? 
+  **Resultados esperados**: depois que as consultas e o código forem executados, qual é o resultado esperado do manual? 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [SEC10-BP02 - Develop incident management plans (SEC10-BP02 – Desenvolver planos de gerenciamento de incidentes)](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html) 

 **Documentos relacionados:** 
+  [Framework for Incident Response Playbooks (Estrutura para manuais de resposta a incidentes)](https://github.com/aws-samples/aws-customer-playbook-framework)  
+  [Develop your own Incident Response Playbooks (Desenvolva seus próprios manuais de resposta a incidentes)](https://github.com/aws-samples/aws-incident-response-playbooks-workshop)  
+  [Incident Response Playbook Samples (Amostras do manual de resposta a incidentes)](https://github.com/aws-samples/aws-incident-response-playbooks)  
+  [Building an AWS incident response runbook using Jupyter playbooks and CloudTrail Lake](https://catalog.workshops.aws/incident-response-jupyter/en-US)  

 

# SEC10-BP05 Acesso pré-provisionado
<a name="sec_incident_response_pre_provision_access"></a>

Verifique se os respondentes a incidentes têm o acesso correto pré-provisionado na AWS para reduzir o tempo de investigação necessário até a recuperação.

 **Antipadrões comuns:** 
+  Uso da conta raiz para a resposta a incidentes. 
+  Alteração de contas de usuário existentes. 
+  Manipulação de permissões do IAM diretamente ao fornecer elevação de privilégios just-in-time. 

 **Nível de risco exposto se essa prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

A AWS recomenda reduzir ou eliminar a dependência de credenciais de longa duração sempre que possível, dando preferência a credenciais temporárias e *a mecanismos de escalação de privilégios* just-in-time. As credenciais de longa duração são propensas a riscos de segurança e aumentam a sobrecarga operacional. Para a maioria das tarefas de gerenciamento, bem como tarefas de resposta a incidentes, recomendamos a implementação da [federação de identidades](https://docs.aws.amazon.com/identity/federation/) junto com a [escalação temporária para acesso administrativo](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/). Nesse modelo, um usuário solicita elevação a um nível superior de privilégio (como um perfil de resposta a incidentes) e, considerando que ele seja elegível para a elevação, a solicitação é enviada a um aprovador. Se a solicitação for aprovada, o usuário receberá um conjunto de credenciais [temporárias da AWS,](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) que podem ser usadas para concluir suas tarefas. Depois que essas credenciais expirarem, o usuário deve enviar uma nova solicitação de elevação.

 Recomendamos o uso da escalação de privilégio temporária para a maioria dos cenários de resposta a incidentes. A maneira correta de fazer isso é com o uso do [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) e [de políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) para definir o escopo de acesso. 

 Há cenários em que as identidades federadas não estão disponíveis, como: 
+  Interrupção relacionada a um provedor de identidades (IdP) comprometido. 
+  Erro de configuração ou erro humano causando uma falha no sistema de gerenciamento de acesso federado. 
+  Atividade mal-intencionada, como um evento de negação de serviço distribuído (DDoS) ou indisponibilidade de renderização do sistema. 

 Nos casos anteriores, deverá haver um acesso de emergência de *breaking-glass* configurado para permitir a investigação e a correção em tempo hábil dos incidentes. Recomendamos a utilização de um [usuário do IAM com as permissões apropriadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) para realizar tarefas e acessar os recursos da AWS. Use as credenciais raiz somente para [tarefas que exijam o acesso do usuário raiz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Para verificar se os respondentes de um incidente têm o nível de acesso correto à AWS e a outros sistemas relevantes, recomendamos o pré-provisionamento de contas de usuário dedicadas. As contas de usuário exigem acesso privilegiado e devem ser estritamente controladas e monitoradas. As contas devem ser criadas com os menores privilégios exigidos para realizar as tarefas necessárias, e o nível de acesso deve ser baseado nos manuais criados como parte do plano de gerenciamento de incidentes. 

 Utilize perfis e usuários dedicados e com propósito específico como uma prática recomendada. Escalar temporariamente o acesso de usuários ou perfis por meio da adição de políticas do IAM não deixa claro qual é o acesso que os usuários tinham durante o incidente, e há um risco de que os privilégios escalados não sejam revogados. 

 É importante remover o máximo de dependências possível para verificar se o acesso pode ser obtido com o maior número possível de cenários de falha. Para apoiar isso, crie um manual para verificar se os usuários de resposta a incidentes são criados como usuários do AWS Identity and Access Management em uma conta de segurança dedicada, e não são gerenciados por nenhuma solução de autenticação única (SSO) ou federação. Cada respondente individual deve ter sua própria conta nomeada. A configuração da conta deve aplicar uma [política de senha forte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) e a autenticação multifator (MFA). Se os manuais de resposta a incidentes só exigem acesso ao Console de gerenciamento da AWS, o usuário não deve ter chaves de acesso configuradas e deve ser proibido explicitamente de criar chaves de acesso. Isso pode ser configurado com políticas do IAM ou políticas de controle de serviços (SCPs), conforme mencionado nas Práticas recomendadas de segurança da AWS para [SCPs do AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Os usuários não devem ter privilégios além da capacidade de assumir perfis de resposta a incidentes em outras contas. 

 Durante um incidente, pode ser necessário conceder acesso a outros indivíduos internos ou externos para apoiar a investigação, a correção ou as atividades de recuperação. Nesse caso, use o mecanismo do manual mencionado anteriormente, e deve haver um processo para verificar se qualquer acesso adicional foi revogado imediatamente após a conclusão do incidente. 

 Para verificar se o uso de perfis de resposta a incidentes pode ser monitorado e auditado corretamente, é essencial que as contas de usuário do IAM criadas para esse fim não sejam compartilhadas entre indivíduos e que o usuário raiz da Conta da AWS não seja utilizado, a menos que isso seja [exigido para uma tarefa específica](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Se o usuário raiz for exigido (por exemplo, quando o acesso do IAM a uma conta específica estiver indisponível), use um processo distinto com um manual disponível para verificar a disponibilidade da senha e do token de MFA do usuário raiz. 

 Para configurar as políticas do IAM para os perfis de resposta a incidentes, considere o uso do [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) para gerar políticas baseadas em logs do AWS CloudTrail. Para fazer isso, conceda acesso de administrador ao perfil de resposta a incidentes em uma conta de não produção e execute de acordo com os manuais. Depois da conclusão, pode ser criada uma política que permita somente as ações realizadas. Essa política pode ser então aplicada a todos os perfis de resposta a incidentes em todas as contas. Você pode criar uma política do IAM separada para cada manual a fim de facilitar o gerenciamento e a auditoria. Exemplos de manuais podem incluir planos de resposta para ransomware, violações de dados, perda de acesso da produção, dentre outros cenários. 

 Use as contas de usuário de resposta a incidentes para assumir funções do [IAM de resposta a incidentes em outras Contas da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html). Esses perfis também devem ser configurados para só poderem ser assumidos por usuários na conta de segurança, e o relacionamento de confiança deve exigir que a entidade principal que está fazendo a chamada seja autenticada com MFA. Os perfis devem usar políticas do IAM com escopo estritamente definido para controlar o acesso. Garanta que todas as solicitações `AssumeRole` para esses perfis estejam conectadas no CloudTrail e sejam alertadas, e que as ações realizadas usando esses perfis sejam registradas. 

 É altamente recomendável que as contas de usuário do IAM e os perfis do IAM sejam claramente nomeados para permitir que sejam encontrados com facilidade nos logs do CloudTrail. Um exemplo disso seria nomear as contas do IAM como `<USER_ID>-BREAK-GLASS` e os perfis do IAM como `BREAK-GLASS-ROLE`. 

 [O CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) é usado para registrar as atividades da API em suas contas da AWS e deve ser usado para [configurar alertas sobre o uso dos perfis de resposta a incidentes](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/). Consulte a publicação do blog sobre como configurar alertas quando as chaves raiz são usadas. As instruções podem ser modificadas para configurar a métrica do [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) filtro a filtro em eventos `AssumeRole` relacionados ao perfil do IAM de resposta a incidentes: 

```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```

 Como é provável que os perfis de resposta a incidentes tenham um alto nível de acesso, é importante que esses alertas sejam transmitidos a um grande grupo e que sejam tomadas atitudes rapidamente. 

 Durante um incidente, é possível que um respondente possa exigir acesso a sistemas que não são protegidos diretamente pelo IAM. Isso pode incluir instâncias do Amazon Elastic Compute Cloud, bancos de dados do Amazon Relational Database Service ou plataformas de software como serviço (SaaS). É altamente recomendável que, em vez de usar protocolos nativos, como SSH ou RDP, o [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) seja usado para todo acesso administrativo a instâncias do Amazon EC2. Esse acesso pode ser controlado usando o IAM, que é protegido e auditado. Também pode ser possível automatizar partes de seus manuais usando os documentos do [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html), o que pode reduzir os erros do usuário e melhorar o tempo de recuperação. Para acesso aos bancos de dados e a ferramentas de terceiros, recomendamos armazenar as credenciais de acesso no AWS Secrets Manager e conceder acesso aos perfis de respondente a incidentes. 

 Por fim, o gerenciamento das contas de usuário do IAM de resposta a incidentes deve ser adicionado aos seus processos de [junção, migração e saída,](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) além de ser revisado e testado periodicamente visando confirmar se somente o acesso pretendido é permitido. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Managing temporary elevated access to your AWS environment (Gerenciamento de acesso elevado temporário ao seu ambiente da AWS)](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) 
+  [AWS Security Incident Response Guide (Guia de resposta a incidentes de segurança da AWS) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+  [Recuperação de desastres do AWS Elastic](https://aws.amazon.com/disaster-recovery/) 
+  [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [Setting an account password policy for IAM users (Definição de uma política de senhas de contas para usuários do IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 
+  [Using multi-factor authentication (MFA) in AWS (Uso da autenticação multifator (MFA) na AWS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) 
+ [ Configuring Cross-Account Access with MFA (Configuração do acesso entre contas com MFA) ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ Using IAM Access Analyzer to generate IAM policies (Uso do IAM Access Analyzer para gerar políticas do IAM) ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [ Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment (Práticas recomendadas para políticas de controle de serviço do AWS Organizations em um ambiente de várias contas) ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ How to Receive Notifications When Your AWS Account’s Root Access Keys Are Used (Como receber notificações quando as chaves de acesso raiz da sua conta da AWS são usadas) ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ Create fine-grained session permissions using IAM managed policies (Criar permissões de sessão refinadas usando políticas gerenciadas pelo IAM) ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)

 **Vídeos relacionados:** 
+ [ Automating Incident Response and Forensics in AWS (Automação de resposta a incidentes e investigações forenses na AWS) ](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+  [Guia DIY (faça você mesmo) para runbooks, relatórios de incidentes e resposta a incidentes](https://youtu.be/E1NaYN_fJUo) 
+ [ Prepare for and respond to security incidents in your AWS environment (Prepare-se e responda a incidentes de segurança no ambiente da AWS) ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **Exemplos relacionados:** 
+ [ Lab: AWS Account Setup and Root User (Laboratório: usuário raiz e configuração de conta da AWS) ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ Lab: Incident Response with AWS Console and CLI (Laboratório: resposta a incidentes com o console e a CLI da AWS) ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP06 Pré-implantação de ferramentas
<a name="sec_incident_response_pre_deploy_tools"></a>

Verifique se o pessoal de segurança tem as ferramentas certas pré-implantadas para reduzir o tempo de investigação até a recuperação.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Para automatizar as funções de resposta e operações de segurança, você pode usar um conjunto abrangente de APIs e ferramentas da AWS. Você pode automatizar totalmente os recursos de gerenciamento de identidade, segurança de rede, proteção de dados e monitoramento e disponibilizá-los com métodos populares de desenvolvimento de software já em vigor. Quando você cria a automação da segurança, seu sistema pode monitorar, analisar e iniciar uma resposta, em vez de fazer com que as pessoas monitorem a sua posição de segurança e reajam manualmente a eventos. 

 Se as equipes de resposta a incidentes continuarem a responder aos alertas da mesma forma, há o risco de se acostumarem aos alertas. Com o passar do tempo, a equipe pode se tornar dessensibilizada para alertas e cometer erros ao lidar com situações comuns ou perder alertas incomuns. A automação ajuda a evitar a exaustão de alertas usando funções que processam alertas repetitivos e comuns, permitindo que as pessoas lidem com incidentes confidenciais e exclusivos. A integração de sistemas de detecção de anomalias, como Amazon GuardDuty, AWS CloudTrail Insights e Amazon CloudWatch Anomaly Detection, pode reduzir a carga de alertas baseados em limites comuns. 

 Você pode melhorar os processos manuais com a automatização programática das etapas do processo. Depois de definir o padrão de correção para um evento, você pode decompor esse padrão em lógica acionável e desenvolver o código para executar essa lógica. Os respondentes podem executar esse código para corrigir o problema. Com o passar do tempo, você pode automatizar mais e mais etapas e, por fim, lidar automaticamente com classes inteiras de incidentes comuns. 

 Durante uma investigação de segurança, você precisa ser capaz de analisar os logs relevantes para registrar e compreender o escopo completo e o cronograma do incidente. Os logs também são necessários para geração de alertas indicando que ocorreram determinadas ações de interesse. É essencial selecionar, ativar, armazenar e configurar mecanismos de consulta, recuperação e definir alertas. Além disso, uma forma eficaz de fornecer ferramentas para pesquisar dados de log é o [Amazon Detective](https://aws.amazon.com/detective/). 

 A AWS oferece mais de 200 serviços em nuvem e milhares de recursos. Recomendamos que você analise os serviços que podem apoiar e simplificar sua estratégia de resposta a incidentes. 

 Além do registro em log, você deve desenvolver e implementar uma estratégia [consistente de marcação](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). A marcação pode ajudar a fornecer contexto sobre a finalidade de um recurso da AWS. A marcação também pode ser usada para automação. 

### Etapas da implementação
<a name="implementation-steps"></a>

 **Selecione e configure logs para análise e alertas** 

 Consulte a documentação a seguir sobre como configurar logs para resposta a incidentes: 
+ [ Logging strategies for security incident response (Estratégias de registro para resposta a incidentes de segurança) ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+  [SEC04-BP01 Configurar registro em log de serviço e aplicação](sec_detect_investigate_events_app_service_logging.md) 

 **Habilite serviços de segurança para oferecer suporte à detecção e resposta** 

 A AWS fornece recursos nativos de detecção, prevenção e resposta, e outros serviços podem ser usados para arquitetar soluções de segurança personalizadas. Para obter uma lista dos serviços mais relevantes para resposta a incidentes de segurança, consulte [Definições de capacidade de nuvem](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html). 

 **Desenvolva e implemente uma estratégia de marcação** 

 Obter informações contextuais sobre o caso de uso empresarial e as partes interessadas internas relevantes em torno de um recurso da AWS pode ser difícil. Uma forma de fazer isso é na forma de tags, que atribuem metadados aos recursos da AWS e consistem em uma chave e um valor definidos pelo usuário. Você pode criar tags para categorizar os recursos por finalidade, proprietário, ambiente, tipo de dados processados e outros critérios de sua escolha. 

 Ter uma estratégia de marcação consistente pode acelerar os tempos de resposta e minimizar o tempo gasto no contexto organizacional, permitindo identificar e discernir rapidamente as informações contextuais sobre um recurso da AWS. As tags também podem servir como um mecanismo para iniciar automações de resposta. Para obter mais detalhes sobre o que marcar, consulte [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). Primeiro, você deve definir as tags que deseja implementar em toda a sua organização. Depois disso, você implementará e aplicará essa estratégia de marcação. Para obter mais detalhes sobre implementação e aplicação, consulte [Implement AWS resource tagging strategy using AWS Tag Policies and Service Control Policies (SCPs)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [SEC04-BP01 Configurar registro em log de serviço e aplicação](sec_detect_investigate_events_app_service_logging.md) 
+  [SEC04-BP02 Analisar logs, descobertas e métricas de forma centralizada](sec_detect_investigate_events_analyze_all.md) 

 **Documentos relacionados:** 
+ [ Logging strategies for security incident response (Estratégias de registro para resposta a incidentes de segurança) ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [ Incident response cloud capability definitions (Definições de recursos de nuvem de resposta a incidentes) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html)

 **Exemplos relacionados:** 
+ [ Threat Detection and Response with Amazon GuardDuty and Amazon Detective ](https://catalog.workshops.aws/guardduty/en-US)
+ [ Security Hub Workshop (Workshop do Security Hub) ](https://catalog.workshops.aws/security-hub/en-US)
+ [ Vulnerability Management with Amazon Inspector ](https://catalog.workshops.aws/inspector/en-US)

# SEC10-BP07 Execute simulações
<a name="sec_incident_response_run_game_days"></a>

 À medida que as organizações crescem e evoluem com o tempo, o mesmo acontece com o cenário de ameaças, o que torna importante analisar continuamente seus recursos de resposta a incidentes. Executar simulações (também conhecidas como dias de teste) é um método que pode ser usado para realizar essa avaliação. As simulações usam cenários de eventos de segurança do mundo real projetados para imitar as táticas, as técnicas e os procedimentos (TTPs) de um agente de ameaças e permitir que uma organização exercite e avalie seus recursos de resposta a incidentes respondendo a esses eventos cibernéticos simulados da mesma forma que em uma situação real.

 **Benefícios do estabelecimento dessa prática recomendada:** as simulações têm vários benefícios: 
+  Validar a prontidão cibernética e desenvolver a confiança de seus socorristas. 
+  Testar a precisão e a eficiência de ferramentas e fluxos de trabalho. 
+  Refinar os métodos de comunicação e escalonamento alinhados com seu plano de resposta a incidentes. 
+  Proporcionar uma oportunidade de responder a vetores menos comuns. 

**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Existem três tipos principais de simulações: 
+  **Simulações teóricas:** a abordagem de simulações teóricas é uma sessão baseada em discussões que envolvem as várias partes interessadas na resposta a incidentes para exercer funções e responsabilidades e usar ferramentas de comunicação e manuais estabelecidos. A facilitação das simulações normalmente pode ser realizada em um dia inteiro em um local virtual, local físico ou uma combinação de ambos. Por ser baseada em discussões, a simulação teórica se concentra em processos, pessoas e colaboração. A tecnologia é parte integrante da discussão, mas o uso real de ferramentas ou scripts de resposta a incidentes geralmente não faz parte da simulação teórica. 
+  **Simulações da equipe roxa:** as simulações da equipe roxa aumentam o nível de colaboração entre os respondentes ao incidente (equipe azul) e os agentes de ameaças simuladas (equipe vermelha). A equipe azul é composta por membros do centro de operações de segurança (SOC), mas também pode incluir outras partes interessadas que estariam envolvidas durante um evento cibernético real. A equipe vermelha é composta por uma equipe de testes de penetração ou pelas principais partes interessadas treinadas em segurança ofensiva. A equipe vermelha trabalha em colaboração com os facilitadores da simulação ao projetar um cenário para que este seja preciso e viável. Durante as simulações da equipe roxa, o foco principal está nos mecanismos de detecção, nas ferramentas e nos procedimentos operacionais padrão (SOPs) que apoiam os esforços de resposta a incidentes. 
+  **Simulações da equipe vermelha:** durante uma simulação da equipe vermelha, o infrator (equipe vermelha) realiza uma simulação para atingir um determinado objetivo ou conjunto de objetivos a partir de um escopo predeterminado. Os defensores (equipe azul) não necessariamente terão conhecimento do escopo e da duração da simulação, o que oferece uma avaliação mais realista de como eles responderiam a um incidente real. Como as simulações da equipe vermelha podem ser testes invasivos, tenha cuidado e implemente controles para verificar se a simulação não causa danos reais ao ambiente. 

 Considere facilitar as simulações cibernéticas em intervalos regulares. Cada tipo de simulação pode oferecer benefícios exclusivos aos participantes e à organização como um todo. Portanto, você pode optar por começar com tipos de simulação menos complexos (como simulações teóricas) e avançar para tipos de simulação mais complexos (simulações da equipe vermelha). Você deve selecionar um tipo de simulação com base em sua maturidade de segurança, recursos e resultados desejados. Alguns clientes podem não optar por realizar simulações da equipe vermelha devido à complexidade e ao custo. 

## Etapas da implementação
<a name="implementation-steps"></a>

 Independentemente do tipo de simulação que você escolher, as simulações geralmente seguem estas etapas de implementação: 

1.  **Defina os principais elementos do exercício:** defina o cenário e os objetivos da simulação. Ambos devem ter aceitação da liderança. 

1.  **Identifique as principais partes interessadas:** no mínimo, um exercício precisa de facilitadores e participantes. Dependendo do cenário, outras partes interessadas, como departamento jurídico, de comunicação ou liderança executiva, podem estar envolvidos. 

1.  **Crie e teste o cenário:** talvez o cenário precise ser redefinido durante a criação se elementos específicos não forem viáveis. Espera-se um cenário finalizado como resultado dessa etapa. 

1.  **Facilite a simulação:** o tipo de simulação determina a facilitação usada (um cenário impresso em comparação a um cenário simulado altamente técnico). Os facilitadores devem alinhar suas táticas de facilitação aos objetos da simulação e envolver todos os participantes sempre que possível para proporcionar o máximo benefício. 

1.  **Desenvolva o relatório pós-ação (AAR):** identifique as áreas que funcionaram bem, aquelas que podem ser melhoradas e possíveis déficits. O AAR deve medir a eficácia da simulação, bem como a resposta da equipe ao evento simulado, para que o progresso possa ser monitorado ao longo do tempo com simulações futuras. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) (Guia de resposta a incidentes da AWS) 

 **Vídeos relacionados:** 
+ [AWS GameDay - Security Edition](https://www.youtube.com/watch?v=XnfDWID_OQs) (Dia de jogo da AWS: edição de segurança)

# SEC10-BP08 Estabeleça uma estrutura para aprender com os incidentes
<a name="sec_incident_response_establish_incident_framework"></a>

 A implementação de uma framework *de lições aprendidas* e da capacidade de análise da causa raiz não só ajudará a melhorar os recursos de resposta a incidentes, mas também ajudará a evitar que o incidente se repita. Ao aprender com cada incidente, você pode ajudar a evitar a repetição dos mesmos erros, exposições ou configurações incorretas, não apenas melhorando seu procedimento de segurança, mas também minimizando o tempo perdido em situações evitáveis. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 É importante implementar uma framework *de lições aprendidas* que estabeleça e alcance, em nível geral, os seguintes pontos: 
+  Quando as lições são aprendidas? 
+  O que está envolvido no processo de lições aprendidas? 
+  Como as lições aprendidas são colocadas em prática? 
+  Quem está envolvido no processo e como? 
+  Como as áreas de melhoria serão identificadas? 
+  Como você garantirá que as melhorias sejam monitoradas e implementadas de forma eficaz? 

 A estrutura não deve se concentrar em culpar os indivíduos, mas sim na melhoria de ferramentas e processos. 

### Etapas da implementação
<a name="implementation-steps"></a>

 Além dos resultados de alto nível listados acima, é importante garantir que você faça as perguntas certas para obter o máximo valor (informações que levem a melhorias práticas) do processo. Considere estas perguntas para ajudar você a começar a promover discussões sobre as lições aprendidas: 
+  Qual foi o incidente? 
+  Quando o incidente foi identificado pela primeira vez? 
+  Como ele foi identificado? 
+  Quais sistemas alertaram sobre a atividade? 
+  Quais sistemas, serviços e dados estavam envolvidos? 
+  O que ocorreu especificamente? 
+  O que funcionou bem? 
+  O que não funcionou bem? 
+  Quais processos ou procedimentos falharam ou não tiveram a escala ajustada para responder ao incidente? 
+  O que pode ser melhorado nas seguintes áreas: 
  +  **Pessoas** 
    +  As pessoas que precisavam ser contatadas estavam realmente disponíveis e a lista de contatos estava atualizada? 
    +  As pessoas estavam perdendo treinamentos ou não tinham os recursos necessários para responder e investigar o incidente com eficácia? 
    +  Os recursos apropriados estavam prontos e disponíveis? 
  +  **Processo** 
    +  Os processos e procedimentos foram seguidos? 
    +  Os processos e procedimentos foram documentados e estavam disponíveis para esse (tipo de) incidente? 
    +  Estavam faltando processos e procedimentos necessários? 
    +  Os respondentes conseguiram obter acesso oportuno às informações necessárias para responder ao problema? 
  +  **Tecnologia** 
    +  Os sistemas de alerta existentes identificaram e alertaram efetivamente sobre a atividade? 
    +  Como poderíamos ter reduzido o tempo de detecção em 50%? 
    +  Os alertas existentes precisam ser aprimorados ou novos alertas precisam ser criados para esse (tipo de) incidente? 
    +  As ferramentas existentes permitiram uma investigação (pesquisa/análise) eficaz do incidente? 
    +  O que pode ser feito para ajudar a identificar esse (tipo de) incidente mais cedo? 
    +  O que pode ser feito para ajudar a evitar que esse (tipo de) incidente ocorra novamente? 
    +  Quem é o proprietário do plano de melhoria e como você testará se ele foi implementado? 
    +  Qual é o cronograma para que os controles e processos adicionais de monitoramento ou prevenção sejam implementados e testados? 

 Essa lista não inclui tudo, mas serve como ponto de partida para identificar quais são as necessidades da organização e da empresa e como você pode analisá-las para aprender com os incidentes de forma mais eficaz e melhorar constantemente seu procedimento de segurança. O mais importante é começar incorporando as lições aprendidas como parte padrão do processo de resposta a incidentes, da documentação e das expectativas das partes interessadas. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Security Incident Response Guide - Establish a framework for learning from incidents](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/establish-framework-for-learning.html) 
+  [NCSC CAF guidance - Lessons learned (Orientações do NCSC CAF: lições aprendidas)](https://www.ncsc.gov.uk/collection/caf/caf-principles-and-guidance/d-2-lessons-learned) 

# Segurança de aplicações
<a name="a-appsec"></a>

**Topics**
+ [SEGURANÇA 11. Como incorporar e validar as propriedades de segurança de aplicações durante o ciclo de vida de design, desenvolvimento e implantação?](sec-11.md)

# SEGURANÇA 11. Como incorporar e validar as propriedades de segurança de aplicações durante o ciclo de vida de design, desenvolvimento e implantação?
<a name="sec-11"></a>

Treinar a equipe, testar por meio da automação, entender as dependências e validar as propriedades de segurança de ferramentas e aplicações ajuda a diminuir a probabilidade de problemas de segurança em workloads de produção.

**Topics**
+ [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md)
+ [SEC11-BP03 Realizar teste de penetração regular](sec_appsec_perform_regular_penetration_testing.md)
+ [SEC11-BP04 Análises manuais de código](sec_appsec_manual_code_reviews.md)
+ [SEC11-BP05 Centralizar serviços para pacotes e dependências](sec_appsec_centralize_services_for_packages_and_dependencies.md)
+ [SEC11-BP06 Implantar software programaticamente](sec_appsec_deploy_software_programmatically.md)
+ [SEC11-BP07 Avaliar regularmente as propriedades de segurança dos pipelines](sec_appsec_regularly_assess_security_properties_of_pipelines.md)
+ [SEC11-BP08 Criar um programa que incorpore a propriedade de segurança nas equipes de workload](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md)

# SEC11-BP01 Treinar para segurança de aplicações
<a name="sec_appsec_train_for_application_security"></a>

 Forneça treinamento aos criadores em sua organização sobre práticas comuns para promover a segurança no desenvolvimento e na operação de aplicações. A adoção de práticas de desenvolvimento com foco na segurança ajuda a diminuir a probabilidade de problemas que são detectados somente no estágio de avaliação da segurança. 

**Resultado desejado:** o software deve ser projetado e criado com a segurança em mente. Quando os criadores em uma organização são treinados em práticas de desenvolvimento seguras que começam com um modelo de ameaças, isso melhora a qualidade e a segurança gerais do software produzido. Essa abordagem pode reduzir o tempo de entrega do software ou de recursos porque não é necessário tanto retrabalho após o estágio de avaliação da segurança. 

 Para as finalidades desta prática recomendada, *desenvolvimento seguro* refere-se ao software que está sendo criado e às ferramentas ou aos sistemas compatíveis com o ciclo de vida de desenvolvimento de software (SDLC). 

**Antipadrões comuns:**
+  Aguardar uma avaliação da segurança e, depois, considerar as propriedades de segurança de um sistema. 
+  Deixar todas as decisões de segurança para a equipe de segurança. 
+  Não comunicar como as decisões tomadas no SDLC se relacionam às expectativas ou as políticas de segurança gerais da organização. 
+  Iniciar o processo de avaliação da segurança muito tardiamente. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Melhor conhecimento dos requisitos organizacionais para a segurança na fase inicial do ciclo de desenvolvimento. 
+  Ser capaz de identificar e solucionar possíveis problemas de segurança com maior rapidez, promovendo uma entrega de recursos mais rápida. 
+  Maior qualidade do software e dos sistemas. 

**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Ofereça treinamento aos criadores em sua organização. Iniciar um curso sobre [modelagem de ameaças](https://catalog.workshops.aws/threatmodel/en-US) é uma boa base para ajudar a treinar para segurança. Preferencialmente, os criadores devem ser capazes de acessar de forma independente as informações relevantes às respectivas workloads. Esse acesso os ajuda a tomar decisões embasadas sobre as propriedades de segurança dos sistemas criados por eles sem a necessidade de solicitar outra equipe. O processo para envolver a equipe de segurança para avaliações deve ser claramente definido e simples de seguir. As etapas do processo de avaliação devem ser incluídas no treinamento de segurança. Quando houver padrões ou modelos de implementação disponíveis, eles deverão ser simples de encontrar e vincular aos requisitos de segurança gerais. Considere usar o [AWS CloudFormation,](https://aws.amazon.com/cloudformation/) as [estruturas do AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html), o [Service Catalog](https://aws.amazon.com/servicecatalog/) ou outras ferramentas de modelo para reduzir a necessidade de configuração personalizada. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Oferecer aos criadores um curso sobre [modelagem de ameaças](https://catalog.workshops.aws/threatmodel/en-US) para criar uma boa base e ajudar a treiná-los a pensar em segurança. 
+  Conceder acesso ao treinamento do [Treinamento da AWS and Certification](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult), do setor ou de parceiros da AWS. 
+  Fornecer treinamento sobre o processo de avaliação da segurança de sua organização, que esclarece a divisão de responsabilidades entre a equipe de segurança, as equipes de workload e outras partes interessadas. 
+  Publicar orientações de autoatendimento sobre como atender aos seus requisitos de segurança, inclusive códigos de exemplo e modelos, se disponíveis. 
+  Obter feedback regularmente de equipes de criadores sobre a experiência deles com o processo e o treinamento de processo de avaliação da segurança e usar esse feedback para promover melhorias. 
+  Utilizar dias de jogo ou campanhas de bug bash para ajudar a reduzir o número de problemas e aumentar as habilidades de seus criadores. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC11-BP08 Criar um programa que incorpore a propriedade de segurança nas equipes de workload](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md) 

 **Documentos relacionados:** 
+  [Treinamento da AWS and Certification](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult) 
+  [Como pensar sobre governança de segurança na nuvem](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) 
+  [Como abordar a modelagem de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) 
+  [Como acelerar o treinamento: o AWS Skills Guild](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/accelerating-training-the-aws-skills-guild.html) 

 **Vídeos relacionados:** 
+  [Segurança proativa: considerações e abordagens](https://www.youtube.com/watch?v=CBrUE6Qwfag) 

 **Exemplos relacionados:** 
+  [Workshop sobre modelagem de ameaças](https://catalog.workshops.aws/threatmodel) 
+  [Conscientização do setor para desenvolvedores](https://owasp.org/www-project-top-ten/) 

 **Serviços relacionados:** 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
+  [Estruturas do AWS Cloud Development Kit (AWS CDK) (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html) 
+  [Service Catalog](https://aws.amazon.com/servicecatalog/) 
+  [AWS BugBust](https://docs.aws.amazon.com/codeguru/latest/bugbust-ug/what-is-aws-bugbust.html) 

# SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento
<a name="sec_appsec_automate_testing_throughout_lifecycle"></a>

 Automatize o teste das propriedades de segurança durante o ciclo de vida de desenvolvimento e lançamento. Com a automação, é mais fácil identificar de forma consistente e repetível possíveis problemas no software antes do lançamento, o que reduz o risco de problemas de segurança no software que está sendo fornecido. 

**Resultado esperado: ** o objetivo do teste automatizado é oferecer uma forma programática de detectar possíveis problemas precocemente e com frequência ao longo do ciclo de vida de desenvolvimento. Ao automatizar o teste de regressão, você pode executar novamente testes funcionais e não funcionais para verificar se o software testado anteriormente ainda funciona da forma esperada após uma alteração. Ao definir testes de unidade de segurança para conferir configurações incorretas comuns, como uma autenticação ausente ou danificada, é possível identificar e resolver esses problemas logo no início do processo de desenvolvimento. 

 A automação de testes utiliza casos de teste para um propósito específico para validação de aplicações, com base nos requisitos e na funcionalidade desejada da aplicação. O resultado dos testes automatizados baseia-se na comparação da saída do teste gerado com a respectiva saída esperada, o que acelera o ciclo de vida dos testes em geral. As metodologias de teste, como teste de regressão e pacotes de teste de unidade, são mais adequadas para automação. A automação dos testes de propriedades de segurança possibilita aos criadores receber feedback automatizado sem precisar esperar por uma avaliação da segurança. Os testes automatizados em forma de análise de código estático ou dinâmico podem melhorar a qualidade do código e ajudar a detectar possíveis problemas de software no ciclo de vida de desenvolvimento. 

**Antipadrões comuns:**
+  Não comunicar os casos de teste e os resultados dos testes automatizados. 
+  Realizar os testes automatizados somente antes de um lançamento. 
+  Automatizar casos de teste com requisitos que mudam com frequência. 
+  Não fornecer orientações sobre como abordar os resultados dos testes de segurança. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Redução da dependência de pessoas que avaliam as propriedades de segurança dos sistemas. 
+  Descobertas consistentes em vários fluxos de trabalho que melhoram a consistência. 
+  Redução da probabilidade de introduzir problemas de segurança no software de produção. 
+  Redução do período de tempo entre a detecção e a correção devido à detecção mais antecipada de problemas de software. 
+  Maior visibilidade do problema sistêmico ou repetido entre os vários fluxos de trabalho, o que pode ser utilizado para promover melhorias em toda a organização. 

** Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

Ao criar um software, adote vários mecanismos de teste para garantir que você esteja testando os requisitos funcionais da aplicação, com base na respectiva lógica de negócios e em requisitos não funcionais, os quais se concentram na confiabilidade, performance e segurança da aplicação. 

 O teste de segurança de aplicação estática (SAST) analisa padrões de segurança anômalos no código-fonte e fornece indicações de código propenso a defeitos. O SAST depende de entradas estáticas, como documentação (especificação de requisitos, documentação e especificações de design) e código-fonte da aplicação, para testar uma série de problemas de segurança conhecidos. Os analisadores de código estático podem ajudar a acelerar a análise de grandes volumes de código. O [NIST Quality Group](https://www.nist.gov/itl/ssd/software-quality-group) oferece uma comparação de [analisadores de segurança de código-fonte](https://www.nist.gov/itl/ssd/software-quality-group/source-code-security-analyzers), o que inclui ferramentas de código aberto para [leitores de código de byte](https://samate.nist.gov/index.php/Byte_Code_Scanners.html) e [leitores de código binário](https://samate.nist.gov/index.php/Binary_Code_Scanners.html).

 Complemente seu teste estático com metodologias de teste de segurança de análise dinâmica (DAST), que realizam testes na aplicação em execução a fim de identificar comportamento possivelmente inesperado. O teste dinâmico pode ser utilizado para detectar possíveis problemas que não são detectáveis por meio de análise estática. Por meio dos testes nos estágios de repositório de código, compilação e pipeline, é possível impedir que diferentes tipos de problema em potencial ocorram no código. O [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) oferece recomendações de código, como verificação de segurança, no IDE do criador. O [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) pode identificar problemas críticos, problemas de segurança e bugs difíceis de detectar durante o desenvolvimento da aplicação e oferece recomendações para melhorar a qualidade do código. 

 O workshop [Segurança para desenvolvedores](https://catalog.workshops.aws/sec4devs) utiliza ferramentas de desenvolvedor da AWS, como [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodeCommit](https://aws.amazon.com/codecommit/) e [AWS CodePipeline](https://aws.amazon.com/codepipeline/), para automação de pipeline de lançamento que inclui as metodologias de teste SAST e DAST. 

 À medida que você avançar no SDLC, estabeleça um processo iterativo que inclua avaliações de aplicação periódicas com sua equipe de segurança. O feedback coletado dessas avaliações de segurança deve ser abordado e validado como parte de sua avaliação de prontidão do lançamento. Essas avaliações estabelecem um procedimento de segurança robusto de aplicações e fornecem aos criadores feedback útil para resolver possíveis problemas. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Implementar um IDE consistente, análise de código e ferramentas de CI/CD que incluam teste de segurança. 
+  Considerar quando no SDLC é adequado bloquear pipelines em vez de apenas notificar os criadores de que problemas precisam ser corrigidos. 
+  O workshop [Segurança para desenvolvedores](https://catalog.workshops.aws/sec4devs) fornece um exemplo de como integrar testes estáticos e dinâmicos a um pipeline de lançamento. 
+  Realizar testes ou análise de código com ferramentas automatizadas, como o [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) integrado a IDEs de desenvolvedores e o [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) para verificação do código na confirmação, ajuda os criadores a obter feedback no momento certo. 
+  Ao criar com o AWS Lambda, é possível usar o [Amazon Inspector](https://aws.amazon.com/about-aws/whats-new/2023/02/code-scans-lambda-functions-amazon-inspector-preview/) para verificar o código de aplicação em suas funções. 
+  O workshop [CI/CD na AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) fornece um ponto de partida para criar pipelines de CI/CD na AWS. 
+  Quando testes automatizados são incluídos em pipelines de CI/CD, você precisa usar um sistema de emissão de tíquetes para rastrear a notificação e a correção de problemas de software. 
+  Para testes de segurança que podem gerar descobertas, a vinculação com orientações para correção ajuda os criadores a melhorar a qualidade do código. 
+  Analise regularmente as descobertas das ferramentas automatizadas para priorizar a próxima automação, o treinamento de criadores ou a campanha de conscientização. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Entrega contínua e implantação contínua](https://aws.amazon.com/devops/continuous-delivery/) 
+  [Parceiros com competência em DevOps da AWS](https://aws.amazon.com/devops/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=partner-type%23technology&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-location=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&awsm.page-partner-solutions-cards=1) 
+  [Parceiros de competência em segurança da AWS](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=use-case%23app-security&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc) para segurança da aplicação 
+  [Como escolher uma abordagem de CI/CD do Well-Arquitected](https://aws.amazon.com/blogs/devops/choosing-well-architected-ci-cd-open-source-software-aws-services/) 
+  [Monitorar eventos do CodeCommit no Amazon EventBridge e no Amazon CloudWatch Events](https://docs.aws.amazon.com/codecommit/latest/userguide/monitoring-events.html) 
+  [Análise da detecção de segredos no Amazon CodeGuru Review](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/recommendations.html#secrets-detection) 
+  [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Como a AWS aborda a automação de implantações seguras e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 

 **Vídeos relacionados:**
+  [Sem intervenção manual: como automatizar os pipelines de entrega contínua na Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) 
+  [Como automatizar pipelines CI/CD entre contas](https://www.youtube.com/watch?v=AF-pSRSGNks) 

 **Exemplos relacionados:**
+  [Conscientização do setor para desenvolvedores](https://owasp.org/www-project-top-ten/) 
+  [Governança do AWS CodePipeline](https://github.com/awslabs/aws-codepipeline-governance) 
+  Workshop [Segurança para desenvolvedores](https://catalog.us-east-1.prod.workshops.aws/workshops/66275888-6bab-4872-8c6e-ed2fe132a362/en-US) 
+  [Workshop sobre CI/CD da AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) 

# SEC11-BP03 Realizar teste de penetração regular
<a name="sec_appsec_perform_regular_penetration_testing"></a>

Realize teste de penetração regular do software. Esse mecanismo ajuda a identificar possíveis problemas de software que não podem ser detectados pelo teste automatizado ou por uma análise manual do código. Ele também ajuda você a entender a eficácia dos controles de detecção. O teste de penetração deve tentar determinar se o software pode ser executado de formas inesperadas; por exemplo, expondo dados que devem ser protegidos ou concedendo permissões mais amplas que o esperado.

 

**Resultado desejado:** o teste de penetração é usado para detectar, corrigir e validar as propriedades de segurança da aplicação. O teste de penetração regular e programado deve ser realizado como parte do ciclo de vida de desenvolvimento de software (SDLC). As descobertas do teste de penetração devem ser abordadas antes do lançamento do software. Você precisa analisar as descobertas do teste de penetração para identificar se há problemas que podem ser encontrados usando a automação. Ter um processo de teste de penetração regular e repetível que inclua um mecanismo de feedback ativo ajuda a transmitir as orientações aos criadores e melhora a qualidade do software. 

**Antipadrões comuns:**
+  Realizar um teste de penetração somente para problemas de segurança conhecidos ou prevalentes. 
+  Realizar um teste de penetração em aplicações sem ferramentas e bibliotecas de terceiro dependentes. 
+  Realizar um teste de penetração em aplicações em busca de problemas de segurança de pacote e não avaliar a lógica de negócios implementada. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Maior confiança nas propriedades de segurança do software antes do lançamento. 
+  Oportunidade de identificar padrões de aplicação preferenciais, o que aumenta a qualidade do software. 
+  Um ciclo de feedback que identifica mais cedo no ciclo de desenvolvimento quando a automação ou treinamento adicional pode melhorar as propriedades de segurança do software. 

** Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 O teste de penetração é um exercício de teste de segurança estruturado em que você executa cenários de violação de segurança planejados a fim de detectar, corrigir e validar controles de segurança. Os testes de penetração começam com o reconhecimento, durante o qual os dados são coletados com base no design atual da aplicação e nas respectivas dependências. Uma lista selecionada de cenários de teste específicos de segurança é criada e executada. A principal finalidade desses testes é revelar problemas de segurança em sua aplicação, que podem ser explorados para obter acesso não intencional ao seu ambiente ou acesso não autorizado aos dados. Você precisa realizar o teste de penetração ao lançar novos recursos ou sempre que sua aplicação passar por alterações importantes na implementação técnica ou de funções. 

 É necessário identificar o estágio mais apropriado do ciclo de vida de desenvolvimento para realizar o teste de penetração. Esse teste deve ocorrer em uma fase tardia o suficiente para que a funcionalidade do sistema esteja próxima ao estado de lançamento pretendido, mas com tempo suficiente para corrigir todos os problemas. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Ter um processo estruturado sobre como definir o escopo do teste de penetração. Basear esse processo no [modelo de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) é uma boa forma de manter o contexto. 
+  Identificar o estágio apropriado do ciclo de vida de desenvolvimento para realizar o teste de penetração, que deve ser quando houver o mínimo de alterações esperadas na aplicação e houver tempo suficiente para realizar a correção. 
+  Treinar os criadores sobre o que esperar das descobertas do teste de penetração e como ter informações sobre correção. 
+  Utilizar ferramentas para acelerar o processo de testes de penetração automatizando testes comuns ou repetíveis. 
+  Analisar as descobertas do teste de penetração para identificar problemas de segurança sistêmicos e utilizar esses dados para embasar testes automatizados adicionais e a instrução contínua dos criadores. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md) 
+ [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md)

 **Documentos relacionados:** 
+  [O teste de penetração da AWS](https://aws.amazon.com/security/penetration-testing/) fornece orientações detalhadas para teste de penetração na AWS 
+  [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Parceiros de competência em segurança da AWS](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc) 
+  [Modernize sua arquitetura de teste de penetração no AWS Fargate](https://aws.amazon.com/blogs/architecture/modernize-your-penetration-testing-architecture-on-aws-fargate/) 
+  [AWS Fault injection Simulator](https://aws.amazon.com/fis/) 

 **Exemplos relacionados:** 
+  [Como automatizar testes de API com o AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-codebuild-with-postman) (GitHub) 
+  [Assistente de segurança automatizado](https://github.com/aws-samples/automated-security-helper) (GitHub) 

# SEC11-BP04 Análises manuais de código
<a name="sec_appsec_manual_code_reviews"></a>

Realize uma análise manual do código do software que você produz. Esse processo ajuda a verificar se a pessoa que escreveu o código não é a única que está conferindo a qualidade dele.

**Resultado desejado:** a inclusão de uma etapa de análise de código manual durante o desenvolvimento melhora a qualidade do software que está sendo criado, ajuda a melhorar as habilidades de membros menos experientes da equipe e oferece uma oportunidade de identificar locais onde a automação pode ser usada. É possível oferecer compatibilidade com as análises de código manuais com ferramentas e testes automatizados. 

**Antipadrões comuns:**
+  Não realizar análises de código antes da implantação. 
+  Ter a mesma pessoa para escrever e analisar o código. 
+  Não utilizar a automação para auxiliar ou orquestrar as análises de código. 
+  Não treinar os criadores em segurança de aplicações antes de analisarem o código. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Código de melhor qualidade. 
+  Maior consistência do desenvolvimento do código por meio da reutilização de abordagens comuns. 
+  Redução no número de problemas descobertos durante o teste de penetração e em estágios posteriores. 
+  Maior transferência de conhecimentos na equipe. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 A etapa de análise deve ser implementada como parte do fluxo de gerenciamento de código geral. Os detalhes dependem da abordagem utilizada para ramificação, solicitações de pull e mesclagem. Você pode utilizar o AWS CodeCommit ou soluções de terceiros, como GitHub, GitLab ou Bitbucket. Seja qual for o método utilizado, é importante verificar se seus processos precisam de análise de código antes da implantação em um ambiente de produção. O uso de ferramentas, como o [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html), pode facilitar a orquestração do processo de análise do código. 

### Etapas da implementação
<a name="implementation-steps-required-field"></a>
+  Implementar uma etapa de análise manual como parte do fluxo de gerenciamento de código e realizar essa análise antes de prosseguir. 
+  Considerar o [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) para gerenciar e auxiliar nas análises de código. 
+  Implementar um fluxo de aprovação que exija a realização de uma análise de código antes de avançá-lo para o próximo estágio. 
+  Verificar se há um processo para identificar problemas encontrados durante as análises de código manuais que possam ser detectados automaticamente. 
+  Integrar a etapa de análise de código manual de forma que se alinhe às suas práticas de desenvolvimento de código. 

## Recursos
<a name="resources-required-field"></a>

 **Práticas recomendadas relacionadas:**
+  [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documentos relacionados:**
+  [Trabalhar com solicitações de pull em repositórios do AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/pull-requests.html) 
+  [Trabalhar com modelos de regra de aprovação no AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/approval-rule-templates.html) 
+  [Sobre solicitações de pull no GitHub](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) 
+  [Análises de código automatizadas com o Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/) 
+  [Automatizar a detecção de vulnerabilidades de segurança e bugs em pipelines de CI/CD com o uso da CLI do Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automating-detection-of-security-vulnerabilities-and-bugs-in-ci-cd-pipelines-using-amazon-codeguru-reviewer-cli/) 

 **Vídeos relacionados:**
+  [Melhoria contínua da qualidade do código com o Amazon CodeGuru](https://www.youtube.com/watch?v=iX1i35H1OVw) 

 **Exemplos relacionados:** 
+  Workshop [Segurança para desenvolvedores](https://catalog.workshops.aws/sec4devs) 

# SEC11-BP05 Centralizar serviços para pacotes e dependências
<a name="sec_appsec_centralize_services_for_packages_and_dependencies"></a>

Forneça serviços centralizados a equipes de criadores para obter pacotes de software e outras dependências. Isso permite a validação de pacotes antes que eles sejam incluídos no software que você escreve e fornece uma fonte de dados para a análise do software que está sendo usado na sua organização.

**Resultado desejado:** o software é composto de um conjunto de outros pacotes de software além do código que está sendo escrito. Isso simplifica o consumo de implementações de funcionalidades que são utilizadas repetidamente, como um analisador JSON ou uma biblioteca de criptografia. A centralização lógica das fontes desses pacotes e dependências oferece um mecanismo para as equipes de segurança validarem as propriedades dos pacotes antes de eles serem utilizados. Essa abordagem também reduz o risco de um problema inesperado ser provocado por uma alteração em um pacote existente ou pela inclusão de pacotes arbitrários diretamente da Internet pelas equipes de criadores. Utilize essa abordagem em conjunto com os fluxos de testes manuais e automatizados para aumentar a confiança na qualidade do software que está sendo desenvolvido. 

**Antipadrões comuns:**
+  Extrair pacotes de repositórios arbitrários na Internet. 
+  Não testar novos pacotes antes de disponibilizá-los aos criadores. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Melhor entendimento de quais pacotes estão sendo utilizados no software que está sendo criado. 
+  Capacidade de notificar as equipes de workload quando um pacote precisa ser atualizado com base no entendimento de quem está usando o quê. 
+  Redução do risco de um pacote com problemas ser incluído em seu software. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Forneça serviços centralizados para pacotes e dependências de uma forma simples para os criadores consumirem. Serviços centralizados podem ser centralizados logicamente em vez de implementados como um sistema monolítico. Essa abordagem possibilita fornecer serviços de uma forma que atenda às necessidades dos criadores. Você precisa implementar uma forma eficiente de adicionar pacotes ao repositório quando ocorrem atualizações ou surgem novos requisitos. Serviços da AWS como o [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) ou soluções semelhantes de parceiros da AWS oferecem uma forma de entregar esse recurso. 

### Etapas da implementação:
<a name="implementation-steps"></a>
+ Implementar um serviço de repositório centralizado logicamente disponível em todos os ambientes onde o software é desenvolvido. 
+ Incluir acesso ao repositório como parte do processo de provisionamento de Conta da AWS.
+ Criar automação para testar pacotes antes de serem publicados em um repositório.
+ Manter métricas dos pacotes mais utilizados, das linguagens e das equipes com a maior quantidade de alterações.
+  Fornecer um mecanismo automatizado para as equipes de criadores solicitarem novos pacotes e fornecerem feedback. 
+  Verificar regularmente os pacotes em seu repositório para identificar o possível impacto de problemas recém-descobertos. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documentos relacionados:** 
+  [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Aumentar a segurança de seu pacote com o kit de ferramentas CodeArtifact Package Origin Control](https://aws.amazon.com/blogs/devops/tighten-your-package-security-with-codeartifact-package-origin-control-toolkit/) 
+  [Detectar problemas de segurança no registro em log com o Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/detecting-security-issues-in-logging-with-amazon-codeguru-reviewer/) 
+  [Níveis de cadeia de suprimentos para artefatos de software (SLSA)](https://slsa.dev/) 

 **Vídeos relacionados:** 
+  [Segurança proativa: considerações e abordagens](https://www.youtube.com/watch?v=CBrUE6Qwfag) 
+  [A filosofia de segurança da AWS (re:Invent 2017)](https://www.youtube.com/watch?v=KJiCfPXOW-U) 
+  [Quando a segurança, a proteção e a urgência importam: lidar com o Log4Shell](https://www.youtube.com/watch?v=pkPkm7W6rGg) 

 **Exemplos relacionados:** 
+  [Pipeline de publicação de pacotes de várias regiões](https://github.com/aws-samples/multi-region-python-package-publishing-pipeline) (GitHub) 
+  [Publicar módulos Node.Js no AWS CodeArtifact usando o AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-publish-nodejs-modules) (GitHub) 
+  [Exemplo de pipeline do AWS CDK Java CodeArtifact](https://github.com/aws-samples/aws-cdk-codeartifact-pipeline-sample) (GitHub) 
+  [Distribuir pacotes privados do .NET NuGet com o AWS CodeArtifact](https://github.com/aws-samples/aws-codeartifact-nuget-dotnet-pipelines) (GitHub) 

# SEC11-BP06 Implantar software programaticamente
<a name="sec_appsec_deploy_software_programmatically"></a>

Faça implantações de software de forma programática quando possível. Essa abordagem diminui a probabilidade de falha em uma implantação ou da introdução de um problema inesperado devido a erro humano.

**Resultado desejado: **manter as pessoas longe dos dados é um princípio essencial da criação segura na Nuvem AWS. Esse princípio inclui como implantar seu software. 

 Os benefícios de não contar com pessoas para implantar software é a maior confiança de que o componente testado é o que será implantado e de que a implantação sempre é realizada de forma consistente. O software não deve precisar de alterações para funcionar em diferentes ambientes. O uso dos princípios de desenvolvimento de aplicações de 12 fatores, especificamente a externalização da configuração, possibilita implantar o mesmo código em vários ambientes sem a necessidade de alterações. Assinar de forma criptográfica os pacotes de software é uma boa maneira de garantir que nada tenha sido alterado entre os ambientes. O resultado geral dessa abordagem é reduzir o risco em seu processo de alterações e melhorar a consistência das versões do software. 

**Antipadrões comuns:**
+  Implantar software manualmente em produção. 
+  Realizar alterações manualmente no software para suprir diferentes ambientes. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Maior confiança no processo de lançamento de software. 
+  Redução do risco de uma alteração com falha afetar a funcionalidade dos negócios. 
+  Maior cadência de lançamentos devido ao menor risco de alterações. 
+  Recurso de reversão automática para eventos inesperados durante a implantação. 
+  Capacidade de comprovar de forma criptográfica que o software testado é o software implantado. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Crie a infraestrutura de sua Conta da AWS para remover o acesso humano persistente dos ambientes e use ferramentas de CI/CD para realizar implantações. Projete suas aplicações de forma que os dados da configuração específica do ambiente sejam obtidos de uma fonte externa, como o [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). Assine pacotes depois de testados e valide essas assinaturas durante a implantação. Configure seus pipelines de CI/CD para enviar código da aplicação e usar canários para confirmar a implantação bem-sucedida. Utilize ferramentas como o [AWS CloudFormation](https://aws.amazon.com/cloudformation/) ou o [AWS CDK](https://aws.amazon.com/cdk/) para definir sua infraestrutura; depois, use o [AWS CodeBuild](https://aws.amazon.com/codebuild/) e o [AWS CodePipeline](https://aws.amazon.com/codepipeline/) para realizar operações de CI/CD. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Criar pipelines de CI/CD bem definidos para simplificar o processo de implantação. 
+  O uso do [AWS CodeBuild](https://aws.amazon.com/codebuild/) e do [AWS Code Pipeline](https://aws.amazon.com/codepipeline/) para oferecer recurso de CI/CD simplifica a integração de teste de segurança aos seus pipelines. 
+  Seguir as orientações sobre separação de ambientes no whitepaper [Organizar seu ambiente da AWS com o uso de várias contas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html). 
+  Garantir que não haja nenhum acesso humano persistente aos ambientes nos quais as workloads de produção estão em execução. 
+  Projetar as aplicações para oferecer compatibilidade com a externalização de dados de configuração. 
+  Considerar a implantação com o uso do modelo de implantação azul/verde. 
+  Implementar canários para validar a implantação bem-sucedida do software. 
+  Utilizar ferramentas criptográficas, como o [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) ou o [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/), para assinar e confirmar os pacotes de software que você está implantando. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documentos relacionados:** 
+  [Workshop sobre CI/CD da AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) 
+  [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Automatizar uma implantação prática e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 
+  [Assinatura de código com o uso de CA privada do AWS Certificate Manager e chaves assimétricas do AWS Key Management Service)](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/) 
+  [Assinatura de código: um controle de integridade e confiança para o AWS Lambda](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/) 

 **Vídeos relacionados:** 
+  [Sem intervenção manual: como automatizar os pipelines de entrega contínua na Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) 

 **Exemplos relacionados:** 
+  [Implantações azul/verde com o AWS Fargate](https://catalog.us-east-1.prod.workshops.aws/workshops/954a35ee-c878-4c22-93ce-b30b25918d89/en-US) 

# SEC11-BP07 Avaliar regularmente as propriedades de segurança dos pipelines
<a name="sec_appsec_regularly_assess_security_properties_of_pipelines"></a>

 Aplique os princípios do pilar Segurança do Well-Architected aos seus pipelines, com atenção especial à separação das permissões. Avalie as propriedades de segurança de sua infraestrutura de pipelines. O gerenciamento eficaz da segurança *dos* pipelines permite que você forneça segurança ao software que passa *pelos* pipelines. 

**Resultado desejado: **os pipelines utilizados para criar e implantar o software devem seguir as mesmas práticas recomendadas que qualquer outra workload em seu ambiente. Os testes implementados nos pipelines não devem ser editáveis pelos criadores que os estão utilizando. Os pipelines só devem ter as permissões necessárias para as implantações que eles estão realizando e devem implementar proteções para evitar a implantação em ambientes errados. Os pipelines não devem contar com credenciais de longo prazo e devem ser configurados para emitir o estado de forma que a integridade dos ambientes de compilação possa ser validada. 

**Antipadrões comuns:**
+  Testes de segurança que podem ser ignorados pelos criadores. 
+  Permissões excessivamente amplas para pipelines de implantação. 
+  Pipelines não configurados para validar entradas. 
+  Ausência de análise regular das permissões associadas à infraestrutura de CI/CD. 
+  Uso de credenciais de longo prazo ou codificadas. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Maior confiança na integridade do software que está sendo criado e implantado pelos pipelines. 
+  Capacidade de interromper uma implantação quando há atividade suspeita. 

** Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Iniciar com serviços de CI/CD gerenciados que ofereçam compatibilidade com perfis do IAM reduz o risco de vazamento de credenciais. Aplicar os princípios do pilar Segurança à sua infraestrutura de pipeline de CI/CD pode ajudar você a determinar onde é possível realizar melhorias de segurança. Seguir a [Arquitetura de referência de pipelines de implantação da AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/) é um bom ponto de partida para criar seus ambientes de CI/CD. Analisar regularmente a implementação de pipelines e analisar comportamentos inesperados nos logs pode ajudar você a entender os padrões de uso dos pipelines que estão sendo utilizados para implantar o software. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Iniciar com a [Arquitetura de referência de pipeline de implantação da AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/). 
+  Considerar o uso do [AWS IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/what-is-access-analyzer.html) para gerar de forma programática as políticas de privilégio mínimo do IAM para os pipelines. 
+  Integrar seus pipelines ao monitoramento e aos alertas de forma que você seja notificado de atividade inesperada ou anormal. Para serviços gerenciados da AWS, o [Amazon EventBridge](https://aws.amazon.com/eventbridge/) possibilita rotear dados para destinos, como o [AWS Lambda](https://aws.amazon.com/lambda/) ou o [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Arquitetura de referência de pipeline de implantação da AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/) 
+  [Monitorar o AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html) 
+  [Práticas recomendadas de segurança para o AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html) 

 **Exemplos relacionados:** 
+  [Painel de monitoramento de DevOps](https://github.com/aws-solutions/aws-devops-monitoring-dashboard) (GitHub) 

# SEC11-BP08 Criar um programa que incorpore a propriedade de segurança nas equipes de workload
<a name="sec_appsec_build_program_that_embeds_security_ownership_in_teams"></a>

Crie um programa ou mecanismo que capacite as equipes de criadores a tomar decisões de segurança sobre o software que elas estão criando. Ainda assim é necessário que sua equipe de segurança valide essas decisões durante uma avaliação, mas a incorporação da propriedade de segurança nas equipes de criadores aumenta a velocidade e segurança do processo de criação de workloads. Esse mecanismo também promove uma cultura de propriedade que afeta de forma positiva a operação dos sistemas que você cria.

 

**Resultado desejado: **para incorporar a propriedade de segurança e a tomada de decisão às equipes de criadores, você pode treinar os criadores a pensar sobre segurança ou incrementar o treinamento deles com pessoal de segurança incorporado ou associado às equipes de criadores. As duas abordagens são válidas e possibilitam à equipe tomar decisões de segurança de melhor qualidade logo no início do ciclo de desenvolvimento. Esse modelo de propriedade é baseado em treinamento para segurança de aplicações. Iniciar com o modelo de ameaças para a workload específica ajuda a direcionar o design thinking (pensamento de design) para o contexto apropriado. Outro benefício de ter uma comunidade de criadores concentrados em segurança ou um grupo de engenheiros de segurança que trabalhem com equipes de criadores é que você pode entender mais profundamente como o software é escrito. Esse entendimento ajuda você a determinar as próximas áreas de melhoria em seu recurso de automação. 

**Antipadrões comuns:**
+  Deixar todas as decisões de design de segurança para a equipe de segurança. 
+  Não abordar os requisitos de segurança cedo o suficiente no processo de desenvolvimento. 
+  Não obter feedback dos criadores e do pessoal de segurança sobre a operação do programa. 

**Benefícios do estabelecimento desta prática recomendada:**
+  Redução do tempo para concluir as avaliações de segurança. 
+  Redução dos problemas de segurança que são detectados apenas no estágio de avaliação da segurança. 
+  Melhoria da qualidade geral do software que está sendo escrito. 
+  Oportunidade de identificar e entender problemas sistêmicos ou áreas de melhoria de alto valor. 
+  Redução da quantidade de revisão necessária devido às descobertas da avaliação da segurança. 
+  Melhoria da percepção da função de segurança. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Comece com as orientações em [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md). Depois, identifique o modelo operacional para o programa que você acredita ser o melhor para a sua organização. Os dois padrões principais são treinar os criadores ou incorporar o pessoal de segurança às equipes de criadores. Depois de decidir sobre a abordagem inicial, você precisa criar um piloto com uma equipe de workload ou um grupo pequeno de equipes de workload para comprovar que o modelo funciona para sua organização. O apoio de liderança dos criadores e da segurança da organização contribui para a entrega e o sucesso do programa. À medida que você criar esse programa, é importante selecionar as métricas que podem ser utilizadas para mostrar o valor dele. Saber como a AWS resolveu esse problema é uma boa experiência de aprendizado. A prática recomendada é muito concentrada na mudança e cultura organizacionais. As ferramentas que você utiliza devem ser compatíveis com a colaboração entre as comunidades de criadores e de segurança. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Começar com o treinamento dos criadores para segurança de aplicações. 
+  Criar uma comunidade e um programa de integração para instruir os criadores. 
+  Selecionar um nome para o programa. Guardiões, patrocinadores ou defensores são utilizados com frequência. 
+  Identificar o modelo a ser utilizado: treinar criadores, incorporar engenheiros de segurança e ter perfis de segurança de afinidade. 
+  Identificar patrocinadores do projeto em grupos de segurança e de criadores e possivelmente em outros grupos relevantes. 
+  Rastrear as métricas do número de pessoas envolvidas no programa, o tempo gasto em avaliações e o feedback dos criadores e do pessoal de segurança. Utilizar essas métricas para realizar melhorias. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md) 
+  [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documentos relacionados:** 
+  [Como abordar a modelagem de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) 
+  [Como pensar sobre governança de segurança na nuvem](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) 

 **Vídeos relacionados:** 
+  [Segurança proativa: considerações e abordagens](https://www.youtube.com/watch?v=CBrUE6Qwfag) 

# Confiabilidade
<a name="a-reliability"></a>

O pilar Confiabilidade abrange a capacidade de uma workload de executar a função pretendida correta e consistentemente quando esperado. Você pode encontrar orientações prescritivas sobre implementação no [whitepaper sobre o pilar de confiabilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp).

**Topics**
+ [Fundamentos](a-foundations.md)
+ [Arquitetura da carga de trabalho](a-workload-architecture.md)
+ [Gerenciamento de alterações](a-change-management.md)
+ [Gerenciamento de falhas](a-failure-management.md)

# Fundamentos
<a name="a-foundations"></a>

**Topics**
+ [CONFIABILIDADE 1. Como gerenciar as Service Quotas e restrições?](rel-01.md)
+ [CONFIABILIDADE 2. Como planejar sua topologia de rede?](rel-02.md)

# CONFIABILIDADE 1. Como gerenciar as Service Quotas e restrições?
<a name="rel-01"></a>

Para arquiteturas de workload baseadas na nuvem, há Service Quotas, que também são conhecidas como limites de serviço. Essas cotas existem para evitar o provisionamento acidental de mais recursos do que o necessário e para limitar as taxas de solicitação nas operações de API para proteger os serviços contra abuso. Há também restrições de recursos, por exemplo, a taxa de envio de bits por um cabo de fibra óptica ou a quantidade de armazenamento em um disco físico. 

**Topics**
+ [REL01-BP01 Conhecimento das cotas e restrições de serviço](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 Acomodar as restrições e as cotas fixas de serviço por meio da arquitetura](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 Monitorar e gerenciar cotas](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Automatizar o gerenciamento de cotas](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Garantir que existe uma lacuna suficiente entre as cotas atuais e o uso máximo para acomodar o failover](rel_manage_service_limits_suff_buffer_limits.md)

# REL01-BP01 Conhecimento das cotas e restrições de serviço
<a name="rel_manage_service_limits_aware_quotas_and_constraints"></a>

 Esteja ciente das suas cotas padrão e das solicitações de aumento de cota referentes à sua arquitetura de workload. Saiba quais restrições de recursos, como disco ou rede, podem gerar impactos. 

 **Resultado desejado:** os clientes conseguem evitar a degradação ou a interrupção do serviço nas Contas da AWS implementando diretrizes adequadas para monitorar as principais métricas, análises da infraestrutura e etapas de remediação da automação, a fim de confirmar que as cotas e as restrições do serviço não foram atingidas, o que poderia causar degradação ou interrupção do serviço. 

 **Antipadrões comuns:** 
+ Implantar uma workload sem compreender as cotas flexíveis ou fixas e seus limites para os serviços utilizados. 
+ Implantar uma workload de substituição sem analisar e reconfigurar as cotas necessárias ou entrar em contato com o suporte com antecedência. 
+ Pressupor que os serviços em nuvem não têm limites e os serviços podem ser usados sem considerar taxas, limites, contagens e quantidades.
+  Pressupor que as cotas aumentarão automaticamente. 
+  Não saber o processo e a linha de tempo das solicitações de cota. 
+  Pressupor que a cota de serviço em nuvem padrão é idêntica para todos os serviços em comparação entre as regiões. 
+  Pressupor que as restrições do serviço podem ser violadas e os sistemas vão ser escalados automaticamente ou aumentar o limite além das restrições do recurso 
+  Não testar a aplicação em tráfego de pico a fim de aplicar tensão na utilização de seus recursos. 
+  Provisionar o recurso sem analisar o tamanho necessário dele. 
+  Superprovisionar capacidade selecionando tipos de recurso que superam em muito a necessidade real ou os picos esperados. 
+  Não avaliar os requisitos de capacidade para novos níveis de tráfego antes de um novo evento de cliente ou implantação de uma nova tecnologia. 

 **Benefícios do estabelecimento desta prática recomendada:** o monitoramento e o gerenciamento automatizado de cotas de serviço e restrições de recursos podem reduzir as falhas de forma proativa. As alterações nos padrões de tráfego do serviço de um cliente poderão causar interrupção ou degradação se as práticas recomendadas não forem seguidas. Ao monitorar e gerenciar esses valores em todas as regiões e contas, as aplicações podem ter uma resiliência aprimorada em eventos adversos ou não planejados. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 O Service Quotas é um serviço da AWS que ajuda você a gerenciar as cotas de mais de 250 serviços da AWS em um único local. Além de pesquisar os valores de cotas, você também pode solicitar e acompanhar aumentos de cota no console do Service Quotas ou por meio do AWS SDK. O AWS Trusted Advisor oferece uma verificação de cotas de serviço que exibe o uso e as cotas para certos aspectos de alguns serviços. As cotas de serviço padrão por serviço também estão na documentação da AWS por respectivo serviço, por exemplo, consulte [Cotas da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html). 

 Alguns limites de serviço, como os limites de taxa para APIs limitadas, são definidos no próprio Amazon API Gateway por meio da configuração de um plano de uso. Alguns limites definidos como configuração em seus respectivos serviços incluem IOPS provisionadas, armazenamento do Amazon RDS alocado e alocações de volume do Amazon EBS. O Amazon Elastic Compute Cloud tem seu próprio painel de limites de serviço, que pode ajudar você a gerenciar sua instância, o Amazon Elastic Block Store e os limites de endereços IP elásticos. Se você tiver um caso de uso em que as cotas de serviço afetam a performance de sua aplicação e elas não forem ajustadas às suas necessidades, entre em contato com o Suporte para ver se há mitigações. 

 As cotas de serviço podem ser específicas da região e também pode ser globais por natureza. O uso de um serviço da AWS com a cota atingida fará com que o comportamento dele não seja o esperado e poderá causar interrupção ou degradação do serviço. Por exemplo, a cota de um serviço limita o número de DL Amazon EC2 que pode ser usado em uma região e esse limite poderá ser atingido durante um evento de escalabilidade de tráfego usando grupos do Auto Scaling (ASG). 

 As cotas de serviço de cada conta devem ser avaliadas regularmente quanto ao uso a fim de determinar quais são os limites de serviço apropriados para a conta em questão. Essas cotas de serviço existem como barreiras de proteção operacionais, a fim de impedir o provisionamento acidental de recursos além do necessário. Elas também servem para limitar as taxas de solicitação em operações de API para proteger os serviços contra abuso. 

 Restrições de serviço são diferentes de cotas de serviço. As restrições de serviço representam os limites de um recurso específico conforme definido pelo tipo de recurso em questão. Podem ser a capacidade de armazenamento (por exemplo, o gp2 tem um limite de tamanho de 1 GB a 16 TB) ou o throughput de disco (10 mil iops). É essencial que a restrição de um tipo de recurso seja projetada e avaliada constantemente quanto ao uso que pode atingir o limite. Se uma restrição for atingida de modo inesperado, as aplicações da conta ou os serviços poderão sofrer degradação ou interrupção. 

 Se houver um caso de uso em que as cotas de serviço afetem a performance de uma aplicação e elas não puderem ser ajustadas às necessidades, entre em contato com o Suporte para ver se há mitigações. Para obter mais detalhes sobre o ajuste de cotas fixas, consulte [REL01-BP03 Acomodar as restrições e as cotas fixas de serviço por meio da arquitetura](rel_manage_service_limits_aware_fixed_limits.md). 

 Há uma série de serviços e ferramentas da AWS para ajudar a monitorar e gerenciar o Service Quotas. O serviço e as ferramentas devem ser utilizadas para oferecer verificações automatizadas ou manuais dos níveis de cota. 
+  O AWS Trusted Advisor oferece uma verificação de cotas de serviço que exibe o uso e cotas para alguns aspectos de alguns serviços. Ele pode ajudar na identificação de serviços que estão próximos da cota. 
+  O Console de gerenciamento da AWS oferece métodos para exibir valores de cota de serviço, gerenciar, solicitar novas cotas, monitorar o status das solicitações de cota e exibir o histórico de cotas. 
+  A AWS CLI e os CDKs oferecem métodos programáticos para gerenciar e monitorar automaticamente os níveis e o uso de cotas de serviço. 

 **Etapas da implementação** 

 Para Service Quotas: 
+ [ Analisar o AWS Service Quotas. ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+  Para saber suas cotas de serviço existentes, determine os serviços (como o IAM Access Analyzer) utilizados. Há cerca de 250 serviços da AWS controlados por cotas de serviço. Depois, determine o nome específico da cota de serviço que pode estar sendo usada em cada conta e região. Há cerca de 3 mil nomes de cota de serviço por região. 
+  Incremente essa análise de cota com o AWS Config para encontrar todos os [recursos da AWS](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html) utilizados em suas Contas da AWS. 
+  Use [dados do AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html) para determinar seus recursos da AWS utilizados. Examine os recursos que foram criados no Console de gerenciamento da AWS ou com o comando [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html) da AWS CLI. Você também pode ver no próprio modelo os recursos configurados para implantação. 
+  Examine o código da implantação para determinar todos os serviços necessários à sua workload. 
+  Determine as cotas de serviço aplicáveis. Use as informações acessíveis programaticamente por meio do Trusted Advisor e do Service Quotas. 
+  Estabeleça um método de monitoramento automatizado (consulte [REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões](rel_manage_service_limits_limits_considered.md) e [REL01-BP04 Monitorar e gerenciar cotas](rel_manage_service_limits_monitor_manage_limits.md)) para alertar e informar se as cotas de serviço estiverem perto do limite ou o atingirem. 
+  Estabeleça um método automatizado e programático para conferir se uma cota de serviço foi alterada em uma região, mas não em outras na mesma conta (consulte [REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões](rel_manage_service_limits_limits_considered.md) e [REL01-BP04 Monitorar e gerenciar cotas](rel_manage_service_limits_monitor_manage_limits.md)). 
+  Automatize as verificações de logs e métricas de aplicações para determinar se há erros de restrição de serviço ou cota. Se houver esses erros, envie alertas ao sistema de monitoramento. 
+  Estabeleça os procedimentos de engenharia para calcular a alteração necessária na cota (consulte [REL01-BP05 Automatizar o gerenciamento de cotas](rel_manage_service_limits_automated_monitor_limits.md)) depois de identificar que são necessárias cotas maiores para serviços específicos. 
+  Crie um fluxo de trabalho de provisionamento e aprovação para solicitar alterações na cota de serviço. Isso deve incluir um fluxo de trabalho de exceção em caso de negação de solicitação ou aprovação parcial. 
+  Crie um método de engenharia para analisar cotas de serviço antes de provisionar e usar novos serviços da AWS antes de distribuir na produção ou carregar ambientes (por exemplo, conta de teste de carga). 

 Para restrições de serviço: 
+  Estabeleça métodos de monitoramento e métricas para alertar sobre recursos que estejam próximos de suas restrições de recurso. Utilize o CloudWatch conforme apropriado para métricas ou monitoramento de logs. 
+  Estabeleça limites de alerta para cada recurso que tenha uma restrição significativa para a aplicação ou o sistema. 
+  Crie um fluxo de trabalho e procedimentos de gerenciamento de infraestrutura para alterar o tipo de recurso se a restrição estiver próxima da utilização. Esse fluxo de trabalho deve incluir testes de carga como prática recomendada para verificar se o novo tipo de recurso é o correto com as novas restrições. 
+  Migre o recurso identificado para o novo tipo de recurso usando os procedimentos e os processos existentes. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões](rel_manage_service_limits_limits_considered.md) 
+  [REL01-BP03 Acomodar as restrições e as cotas fixas de serviço por meio da arquitetura](rel_manage_service_limits_aware_fixed_limits.md) 
+  [REL01-BP04 Monitorar e gerenciar cotas](rel_manage_service_limits_monitor_manage_limits.md) 
+  [REL01-BP05 Automatizar o gerenciamento de cotas](rel_manage_service_limits_automated_monitor_limits.md) 
+  [REL01-BP06 Garantir que existe uma lacuna suficiente entre as cotas atuais e o uso máximo para acomodar o failover](rel_manage_service_limits_suff_buffer_limits.md) 
+  [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md) 

 **Documentos relacionados:** 
+ [AWS Pilar Confiabilidade da Well-Architected Framework: Disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor Best Practice Checks (Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Service Limits (Limites de serviço))](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS limit monitor on AWS answers](https://aws.amazon.com/answers/account-management/limit-monitor/) (Monitor de limites da AWS em respostas da AWS) 
+  [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) (Limites de serviço do Amazon EC2) 
+  [What is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) (O que é o Service Quotas?) 
+ [ How to Request Quota Increase ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Como solicitar aumento de cota)
+ [ Service endpoints and quotas ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) (Endpoints e cotas de serviço)
+  [Guia do usuário do Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/) (Monitor de cotas da AWS)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [AWS para dados ](https://aws.amazon.com/data/)
+ [ O que significa integração contínua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ O que significa distribuição contínua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/) (Gerenciar o ciclo devida da conta em ambientes de SaaS de conta por locatário na AWS)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/) (Gerenciar e monitorar o controle de utilização de API em workloads)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/) (Exibir recomendações do AWS Trusted Advisor em grande escala com AWS Organizations)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/) (Automatizar aumentos de limite de serviço e suporte empresarial com AWS Control Tower)

 **Vídeos relacionados:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc) (Exibir e gerenciar cotas para serviços da AWS usando o Service Quotas)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ) (Demonstração de cotas do AWS IAM)

 **Ferramentas relacionadas:** 
+ [ Amazon CodeGuru Reviewer ](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões
<a name="rel_manage_service_limits_limits_considered"></a>

 Se você estiver usando várias contas ou regiões, solicite as cotas adequadas em todos os ambientes nos quais suas workloads de produção são executadas. 

 **Resultado desejado:** os serviços e as aplicações não devem ser afetados pelo esgotamento da cota de serviço para configurações que abrangem contas ou regiões ou que têm designs de resiliência que usam failover de conta, zona ou região. 

 **Antipadrões comuns:** 
+ Permitir que a utilização de recursos em uma região de isolamento aumente sem nenhum mecanismo para manter a capacidade das demais. 
+  Configurar manualmente todas as cotas nas regiões de isolamento de forma independente. 
+  Não considerar o efeito das arquiteturas de resiliência (como ativa ou passiva) em necessidades futuras de cota durante a degradação na região que não é a principal. 
+  Não avaliar as cotas regularmente e fazer alterações necessárias em cada região e conta nas quais a workload é executada. 
+  Não utilizar [modelos de solicitação de cota](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html) para solicitar aumentos em várias regiões e contas. 
+  Não atualizar as cotas de serviço por imaginar incorretamente que aumentar as cotas tem implicações de custo, como solicitações de reserva computacional. 

 **Benefícios do estabelecimento desta prática recomendada:** confirmar que você pode lidar com sua carga atual em contas ou regiões secundárias se os serviços regionais ficarem indisponíveis. Isso pode ajudar a reduzir o número de erros ou níveis de degradações que ocorrem durante a perda da região. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Cotas de serviço são rastreadas por conta. A menos que especificado de outra forma, cada cota é específica da Região da AWS. Além dos ambientes de produção, gerencie também as cotas em todos os ambientes aplicáveis que não são de produção, para que os testes e o desenvolvimento não sejam dificultados. Manter um alto grau de resiliência exige que as cotas de serviço sejam avaliadas de forma contínua (sejam elas automatizadas ou manuais). 

 Com mais workloads abrangendo regiões devido à implementação de designs usando as abordagens *Ativo/Ativo*, *Ativo/Passivo: Quente*, *Ativo/Passivo: Frio* e *Ativo/Passivo: Luz piloto*, é essencial entender todos os níveis de cota de contas e regiões. Padrões de tráfego passados nem sempre são um bom indicador de que a cota de serviço está definida corretamente. 

 Igualmente importante, o limite do nome da cota de serviço nem sempre é o mesmo para cada região. Em uma região, o valor pode ser cinco e em outra região pode ser dez. O gerenciamento dessas cotas deve abranger todos os mesmos serviços, contas e regiões para fornecer resiliência consistente sob carga. 

 Reconcilie todas as diferenças de cota de serviço em todas as diferentes regiões (Região ativa ou Região passiva) e crie processos para reconciliar de forma contínua essas diferenças. Os planos de teste de failovers de região passiva raramente são escalados para a capacidade ativa de pico, o que significa que os exercícios de simulações teóricas e dias de teste podem não encontrar diferenças em cotas de serviço entre regiões e também depois manter os limites corretos. 

 É muito importante rastrear e avaliar o *desvio de cotas de serviço*, a condição em que os limites de uma cota de serviço específica são alterados em uma região e não em todas. É necessário pensar em alterar a cota em regiões com tráfego ou que possam ter tráfego. 
+  Selecione as contas e as regiões relevantes conforme seus requisitos de serviço, de latência, regulatórios e de recuperação de desastres. 
+  Identifique as cotas de serviço de todas as contas, regiões e zonas de disponibilidade relevantes. O escopo dos limites é definido para conta e região. Esses valores devem ser comparados em relação a diferenças. 

 **Etapas da implementação** 
+  Analise os valores do Service Quotas que possam ter ultrapassado um nível de risco de uso. O AWS Trusted Advisor oferece alertas para violações de limite de 80% e 90%. 
+  Analise os valores de cotas de serviço em todas as regiões passivas (em um design ativo/passivo). Verifique se a carga será executada com êxito em regiões secundárias em caso de falha na região principal. 
+  Automatize a avaliação se ocorreu algum desvio de cota de serviço entre as regiões na mesma conta e aja adequadamente para alterar os limites. 
+  Se as unidades organizações (UO) do cliente estiverem estruturadas da forma compatível, os modelos de cota de serviço deverão ser atualizados para refletir alterações em todas as cotas que devem ser aplicadas a várias regiões e contas. 
  +  Crie um modelo e associe regiões à alteração de cota. 
  +  Analise todos os modelos de cota de serviço existentes para todas as alterações necessárias (região, limites e contas). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL01-BP01 Conhecimento das cotas e restrições de serviço](rel_manage_service_limits_aware_quotas_and_constraints.md) 
+  [REL01-BP03 Acomodar as restrições e as cotas fixas de serviço por meio da arquitetura](rel_manage_service_limits_aware_fixed_limits.md) 
+  [REL01-BP04 Monitorar e gerenciar cotas](rel_manage_service_limits_monitor_manage_limits.md) 
+  [REL01-BP05 Automatizar o gerenciamento de cotas](rel_manage_service_limits_automated_monitor_limits.md) 
+  [REL01-BP06 Garantir que existe uma lacuna suficiente entre as cotas atuais e o uso máximo para acomodar o failover](rel_manage_service_limits_suff_buffer_limits.md) 
+  [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md) 

 **Documentos relacionados:** 
+ [AWS Pilar Confiabilidade da Well-Architected Framework: Disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor Best Practice Checks (Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Service Limits (Limites de serviço))](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS limit monitor on AWS answers](https://aws.amazon.com/answers/account-management/limit-monitor/) (Monitor de limites da AWS em respostas da AWS) 
+  [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) (Limites de serviço do Amazon EC2) 
+  [What is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) (O que é o Service Quotas?) 
+ [ How to Request Quota Increase ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Como solicitar aumento de cota)
+ [ Service endpoints and quotas ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) (Endpoints e cotas de serviço)
+  [Guia do usuário do Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/) (Monitor de cotas da AWS)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [AWS para dados ](https://aws.amazon.com/data/)
+ [ O que significa integração contínua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ O que significa distribuição contínua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/) (Gerenciar o ciclo devida da conta em ambientes de SaaS de conta por locatário na AWS)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/) (Gerenciar e monitorar o controle de utilização de API em workloads)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/) (Exibir recomendações do AWS Trusted Advisor em grande escala com AWS Organizations)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/) (Automatizar aumentos de limite de serviço e suporte empresarial com AWS Control Tower)

 **Vídeos relacionados:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc) (Exibir e gerenciar cotas para serviços da AWS usando o Service Quotas)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ) (Demonstração de cotas do AWS IAM)

 **Serviços relacionados:** 
+ [ Amazon CodeGuru Reviewer ](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP03 Acomodar as restrições e as cotas fixas de serviço por meio da arquitetura
<a name="rel_manage_service_limits_aware_fixed_limits"></a>

Esteja ciente das cotas de serviço, das restrições do serviço e dos limites de recursos físicos que não podem ser alterados. Projete arquiteturas para aplicações e serviços visando evitar que esses limites afetem a confiabilidade.

Os exemplos incluem largura de banda da rede, tamanho da carga útil da invocação da função sem servidor, taxa de intermitência de aceleração para um gateway da API e conexões simultâneas de usuários com um banco de dados.

 **Resultado desejado:** a aplicação ou o serviço tem o desempenho esperado em condições de tráfego normal e alto. Elas foram projetadas para funcionar com as limitações referentes às restrições ficas ou cotas de serviço do recurso. 

 **Antipadrões comuns:** 
+ Escolher um design que usa um recurso de um serviço sem saber que há restrições de design que causarão falha à medida que você escala.
+ Usar parâmetros de comparação irrealistas e que atingirão as cotas fixas do serviço durante os testes. Por exemplo, executar testes em um limite de intermitência mas por um período estendido.
+  Escolher um design que não possa ser escalado nem modificado caso seja necessário ultrapassar as cotas fixas do serviço. Por exemplo, um tamanho de carga útil do SQS de 256 KB. 
+  A capacidade de observação não foi projetada nem implementada para monitorar e alertar sobre os limites das cotas de serviço que podem estar em risco durante eventos com tráfego alto. 

 **Benefícios do estabelecimento dessa prática recomendada:** verificar se a aplicação será executada em todos os níveis de carga de serviços projetados sem interrupção ou dano. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Ao contrário das cotas de serviço flexíveis ou de recursos que são substituídos com unidades de capacidade mais altas, as cotas fixas dos serviços da AWS não podem ser alteradas. Isso significa que todos esses tipos de serviços da AWS devem ser avaliados com relação a possíveis limites de capacidade rígidos quando usados em um design da aplicação. 

 Os limites rígidos são mostrados no console do Service Quotas. Se a coluna mostrar `ADJUSTABLE = No`, o serviço tem um limite rígido. Os limites rígidos também são mostrados em algumas páginas de configuração de recursos. Por exemplo, o Lambda tem limites rígidos específicos que não podem ser ajustados. 

 Como exemplo, ao projetar uma aplicação Python para ser executada em uma função do Lambda, a aplicação deve ser avaliada para determinar se há alguma chance de o Lambda ser executado por mais de 15 minutos. Se código puder ser executado mais do que esse limite de cota de serviço, tecnologias ou designs alterativos devem ser considerados. Se esse limite for atingido depois da implantação na produção, a aplicação sofrerá uma degradação e interrupção até que isso possa ser corrigido. Ao contrário das cotas flexíveis, não há um método para alterar esses limites mesmo sob eventos de emergência de gravidade 1. 

 Depois que a aplicação for implantada em um ambiente de teste, devem ser usadas estratégias para descobrir se algum limite rígido pode ser atingido. Testes de estresse, testes de carga e testes de caos devem fazer parte do plano de teste de introdução. 

 **Etapas da implementação** 
+  Revise a lista completa de serviços da AWS que poderiam ser usados na fase de design da aplicação. 
+  Revise os limites da cota flexível e os da cota rígida para todos esses serviços. Nem todos os limites são mostrados no console do Service Quotas. Alguns serviços [descrevem esses limites em locais alternativos](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html). 
+  À medida que você planeja a aplicação, revise os fatores que impulsionam a tecnologia e os negócios da workload, como resultados empresariais, casos de uso, sistemas dependentes, destinos de disponibilidade e objetos de recuperação de desastres. Permita que os fatores que impulsionam a tecnologia e os negócios orientem o processo para identificar o sistema distribuído certo para sua workload. 
+  Analise a carga do serviço nas regiões e contas. Muitos limites rígidos são regionais para os serviços. No entanto, alguns limites são por conta. 
+  Analise arquiteturas de resiliência quanto ao uso de recursos durante uma falha de zona e de região. Na progressão de designs de várias regiões usando as abordagens ativo/ativo, ativo/passivo – quente, ativo/passivo – frio e ativo/passivo – luz-piloto, esses casos de falha resultarão em maior uso. Isso cria um possível caso de uso para atingir limites rígidos. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL01-BP01 Conhecimento das cotas e restrições de serviço](rel_manage_service_limits_aware_quotas_and_constraints.md) 
+  [REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões](rel_manage_service_limits_limits_considered.md) 
+  [REL01-BP04 Monitorar e gerenciar cotas](rel_manage_service_limits_monitor_manage_limits.md) 
+  [REL01-BP05 Automatizar o gerenciamento de cotas](rel_manage_service_limits_automated_monitor_limits.md) 
+  [REL01-BP06 Garantir que existe uma lacuna suficiente entre as cotas atuais e o uso máximo para acomodar o failover](rel_manage_service_limits_suff_buffer_limits.md) 
+  [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md) 

 **Documentos relacionados:** 
+ [AWS Pilar Confiabilidade da Well-Architected Framework: Disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor Best Practice Checks (Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Service Limits (Limites de serviço))](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS limit monitor on AWS answers](https://aws.amazon.com/answers/account-management/limit-monitor/) (Monitor de limites da AWS em respostas da AWS) 
+  [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) (Limites de serviço do Amazon EC2) 
+  [What is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) (O que é o Service Quotas?) 
+ [ How to Request Quota Increase ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Como solicitar aumento de cota)
+ [ Service endpoints and quotas ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) (Endpoints e cotas de serviço)
+  [Guia do usuário do Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/) (Monitor de cotas da AWS)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [AWS para dados ](https://aws.amazon.com/data/)
+ [ O que significa integração contínua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ O que significa distribuição contínua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/) (Gerenciar o ciclo devida da conta em ambientes de SaaS de conta por locatário na AWS)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/) (Gerenciar e monitorar o controle de utilização de API em workloads)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/) (Exibir recomendações do AWS Trusted Advisor em grande escala com AWS Organizations)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/) (Automatizar aumentos de limite de serviço e suporte empresarial com AWS Control Tower)
+ [Ações, recursos e chaves de condição do Service Quotas](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)

 **Vídeos relacionados:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc) (Exibir e gerenciar cotas para serviços da AWS usando o Service Quotas)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ) (Demonstração de cotas do AWS IAM)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)(AWS re:Invent 2018: fechar ciclos e abrir mentes: como controlar sistemas, sejam grandes ou pequenos)

 **Ferramentas relacionadas:** 
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP04 Monitorar e gerenciar cotas
<a name="rel_manage_service_limits_monitor_manage_limits"></a>

 Avalie seu uso potencial e aumente suas cotas adequadamente, permitindo o crescimento planejado do uso. 

 **Resultado desejado:** sistemas ativos e automáticos que gerenciam e monitoram foram implantados. Essas soluções garantem que os limites de uso da cota sejam quase atingidos. Isso seria corrigido proativamente por mudanças na cota solicitada. 

 **Antipadrões comuns:** 
+ Não configurar o monitoramento para verificar os limites da cota de serviço.
+ Não configurar o monitoramento de limites rígidos, embora esses valores não possam ser alterados.
+  Presumir que o tempo necessário para solicitar e proteger uma mudança de cota flexível seja imediato ou período curto. 
+  Configurar alarmes para quando as cotas de serviço estiverem sendo atingidas, mas não ter um processo de resposta a um alerta. 
+  Configurar alarmes apenas para serviços compatíveis com o AWS Service Quotas e não monitorar outros serviços da AWS. 
+  Não considerar o gerenciamento da cota para designs com resiliência de várias regiões, como as abordagens ativo/ativo, ativo/passivo – quente, ativo/passivo – frio e ativo/passivo – luz-piloto. 
+  Não avaliar as diferenças de cota entre regiões. 
+  Não avaliar as necessidades de cada região com relação a uma solicitação de aumento de cota específica. 
+  Não utilizar [modelos para o gerenciamento de cota de várias regiões](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html). 

 **Benefícios do estabelecimento dessa prática recomendada:** o rastreamento automático do AWS Service Quotas e o monitoramento do uso em relação a essas cotas permitirão que você veja quando estiver perto de atingir um limite de cota. Também é possível usar esse monitoramento de dados para ajudar a limitar qualquer dano devido à exaustão da cota. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Para dispositivos compatíveis, é possível monitorar as cotas configurando vários serviços diferentes que podem avaliar e, então, enviar alertas ou alarmes. Isso pode auxiliar o monitoramento do uso e alertar quando você estiver se aproximando das cotas. Esses alarmes podem ser acionados pelo AWS Config, por funções do Lambda, pelo Amazon CloudWatch ou pelo AWS Trusted Advisor. Você também pode usar filtros de métrica no CloudWatch Logs para pesquisar e extrair padrões nos logs a fim de determinar se o uso está se aproximando dos limites de cota. 

 **Etapas da implementação** 

 Para monitoramento: 
+  Capture o consumo atual de recursos (por exemplo, buckets ou instâncias). Use operações de API de serviço, como a API do Amazon EC2 `DescribeInstances` para coletar o consumo atual de recursos. 
+  Capture as cotas atuais que são essenciais e aplicáveis aos serviços usando: 
  +  AWS Service Quotas 
  +  AWS Trusted Advisor 
  +  Documentação da AWS 
  +  Páginas específicas de serviços da AWS 
  +  AWS Command Line Interface (AWS CLI) 
  +  AWS Cloud Development Kit (AWS CDK) 
+  Use o AWS Service Quotas, um serviço da AWS que ajuda você a gerenciar as cotas de mais de 250 serviços da AWS em um único local. 
+  Use os limites de serviço do Trusted Advisor para monitorar os limites de serviço atuais em vários limites. 
+  Use o histórico da cota de serviço (console ou AWS CLI) para verificar os aumentos regionais. 
+  Compare as alterações na cota de serviço em cada região e cada conta para criar equivalência, se necessário. 

 Para gerenciamento: 
+  Automático: configure uma regra personalizada do AWS Config para verificar as cotas de serviço nas regiões e comparar as diferenças. 
+  Automático: configure uma função programada do Lambda para verificar as cotas de serviço nas regiões e comparar as diferenças. 
+  Manual: verifique as cotas de serviço por meio da AWS CLI, da API ou do Console da AWS para conferir as cotas de serviço nas regiões e comparar as diferenças. Relate as diferenças. 
+  Se forem identificadas diferenças nas cotas entre as regiões, solicite uma mudança na cota, se necessário. 
+  Avalie o resultado de todas as solicitações. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL01-BP01 Conhecimento das cotas e restrições de serviço](rel_manage_service_limits_aware_quotas_and_constraints.md) 
+  [REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões](rel_manage_service_limits_limits_considered.md) 
+  [REL01-BP03 Acomodar as restrições e as cotas fixas de serviço por meio da arquitetura](rel_manage_service_limits_aware_fixed_limits.md) 
+  [REL01-BP05 Automatizar o gerenciamento de cotas](rel_manage_service_limits_automated_monitor_limits.md) 
+  [REL01-BP06 Garantir que existe uma lacuna suficiente entre as cotas atuais e o uso máximo para acomodar o failover](rel_manage_service_limits_suff_buffer_limits.md) 
+  [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md) 

 **Documentos relacionados:** 
+ [AWS Pilar Confiabilidade da Well-Architected Framework: Disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor Best Practice Checks (Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Service Limits (Limites de serviço))](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS limit monitor on AWS answers](https://aws.amazon.com/answers/account-management/limit-monitor/) (Monitor de limites da AWS em respostas da AWS) 
+  [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) (Limites de serviço do Amazon EC2) 
+  [What is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) (O que é o Service Quotas?) 
+ [ How to Request Quota Increase ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Como solicitar aumento de cota)
+ [ Service endpoints and quotas ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) (Endpoints e cotas de serviço)
+  [Guia do usuário do Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/) (Monitor de cotas da AWS)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [AWS para dados ](https://aws.amazon.com/data/)
+ [ O que significa integração contínua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ O que significa distribuição contínua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/) (Gerenciar o ciclo devida da conta em ambientes de SaaS de conta por locatário na AWS)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/) (Gerenciar e monitorar o controle de utilização de API em workloads)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/) (Exibir recomendações do AWS Trusted Advisor em grande escala com AWS Organizations)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/) (Automatizar aumentos de limite de serviço e suporte empresarial com AWS Control Tower)
+ [Ações, recursos e chaves de condição do Service Quotas](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)

 **Vídeos relacionados:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc) (Exibir e gerenciar cotas para serviços da AWS usando o Service Quotas)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ) (Demonstração de cotas do AWS IAM)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)(AWS re:Invent 2018: fechar ciclos e abrir mentes: como controlar sistemas, sejam grandes ou pequenos)

 **Ferramentas relacionadas:** 
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP05 Automatizar o gerenciamento de cotas
<a name="rel_manage_service_limits_automated_monitor_limits"></a>

 Implemente ferramentas para alertar você quando os limites estiverem perto de serem atingidos. Ao usar as APIs do AWS Service Quotas, você pode automatizar as solicitações de aumento de cota. 

 Se você integrar o Configuration Management Database (CMDB) ou sistema de emissão de tíquetes com o Service Quotas, poderá automatizar o acompanhamento de solicitações de aumento de cota e as cotas atuais. Além do AWS SDK, o Service Quotas oferece automação usando o AWS Command Line Interface (AWS CLI). 

 **Antipadrões comuns:** 
+  Acompanhar as cotas e o uso em planilhas. 
+  Executar relatórios sobre o uso diário, semanal ou mensal e comparar o uso com as cotas. 

 **Benefícios do estabelecimento dessa prática recomendada:** O acompanhamento automatizado das cotas de serviço da AWS e o monitoramento do seu uso em relação a essa cota permitem que você veja quando está perto de atingir um limite. Você pode configurar a automação para ajudá-lo a solicitar um aumento de cota quando necessário. Você pode considerar a redução de algumas cotas quando seu uso estiver na direção oposta para aproveitar os benefícios do risco reduzido (no caso de credenciais comprometidas) e da economia de custos. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Configure o monitoramento automatizado. Implemente ferramentas usando SDKs para alertar você quando os limites estiverem perto de serem atingidos. 
  +  Use o Service Quotas e aumente o serviço com uma solução automatizada de monitoramento de cotas, como o AWS Limit Monitor ou uma oferta do AWS Marketplace. 
    +  [O que é o Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
    +  [Monitoramento de cotas na AWS: solução da AWS](https://aws.amazon.com/answers/account-management/limit-monitor/) 
  +  Configure respostas acionadas com base nos limites de cota por meio do Amazon SNS e das APIs do AWS Service Quotas. 
  +  Teste a automação. 
    +  Configure os limites. 
    +  Integre-se a eventos de alteração do AWS Config, de pipelines de implantação, do Amazon EventBridge ou de terceiros. 
    +  Defina limites baixos fictícios de cota para testar as respostas. 
    +  Configure gatilhos para executar a ação adequada mediante notificações e entre em contato com o AWS Support quando necessário. 
    +  Acione manualmente os eventos de alteração. 
    +  Execute um dia de jogo para testar o processo de alteração de aumento de cota. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management) 
+  [AWS Marketplace: produtos CMDB que ajudam a acompanhar os limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Limites de serviço)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [Monitoramento de cotas na AWS: solução da AWS](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [O que é o Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **Vídeos relacionados:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP06 Garantir que existe uma lacuna suficiente entre as cotas atuais e o uso máximo para acomodar o failover
<a name="rel_manage_service_limits_suff_buffer_limits"></a>

Quando um recurso falha ou fica inacessível, ele ainda pode ser contabilizado nas cotas até ser encerrado com êxito. Verifique se as cotas abrangem a sobreposição de recursos inacessíveis ou com falha e suas substituições. Você deve considerar casos de uso como falha de rede, falha na zona de disponibilidade ou falhas regionais ao calcular essa lacuna.

 **Resultado desejado:** falhas pequenas ou grandes em recursos ou na acessibilidade de recursos podem ser cobertas nos limites atuais do serviço. As falhas de zona, falhas de rede ou até mesmo falhas regionais têm sido consideradas no planejamento de recursos. 

 **Antipadrões comuns:** 
+  Configurar cotas de serviço com base nas necessidades atuais sem considerar os cenários de failover. 
+  Não considerar as entidades principais de estabilidade estática ao calcular a cota de pico de um serviço. 
+  Não considerar o potencial de recursos inacessíveis no cálculo da cota total necessária para cada região. 
+  Não considerar os limites de isolamento de falhas de serviço da AWS para alguns serviços e seus padrões de uso possivelmente anormais. 

 **Benefícios do estabelecimento dessa prática recomendada:** quando um evento de interrupção do serviço afeta a disponibilidade da aplicação, a nuvem permite implementar estratégias para mitigar ou se recuperar desses eventos. Essas estratégias geralmente incluem a criação de recursos adicionais para substituir os que falharam ou estão inacessíveis. Sua estratégia de cota acomodaria essas condições de failover e não incluiria danos adicionais devido à exaustão do limite de serviço. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Ao avaliar os limites de cota, considere casos de failover que podem ocorrer devido a algum dano. Os seguintes tipos de casos de failover devem ser considerados: 
+  Uma VPC interrompida ou inacessível. 
+  Uma sub-rede inacessível. 
+  Uma zona de disponibilidade foi danificada o suficiente para afetar a acessibilidade de muitos recursos. 
+  Várias rotas de rede ou pontos de ingresso e egresso são bloqueados ou alterados. 
+  Uma região foi danificada o suficiente para afetar a acessibilidade de muitos recursos. 
+  Há vários recursos, mas nem todos são afetados por uma falha em uma região ou zona de disponibilidade. 

 Falhas como as da lista acima poderiam ser o gatilho para iniciar um evento de failover. A decisão de fazer failover é única para cada situação e cliente, já que o impacto na empresa pode variar drasticamente. No entanto, ao decidir operacionalmente realizar failover de aplicações ou serviços, o planejamento da capacidade de recursos no local de failover e as cotas relacionadas devem ser solucionados antes do evento. 

 Revise as cotas de cada serviço considerando os picos mais altos do que o normal que podem ocorrer. Esses picos podem estar relacionados aos recursos que podem ser acessados devido às redes ou permissões, mas ainda estão ativos. Os recursos ativos não encerrados ainda serão contabilizados no limite de cota do serviço. 

 **Etapas da implementação** 
+  Verifique se há uma lacuna suficiente entre a cota de serviço e o uso máximo para acomodar um failover ou uma perda de acessibilidade. 
+  Determine suas cotas de serviço, considerando os padrões de implantação, os requisitos de disponibilidade e o aumento do consumo. 
+  Solicite aumentos de cota, se necessário. Planeje o tempo necessário para o atendimento das solicitações de aumento de cota. 
+  Determine os requisitos de confiabilidade (também conhecidos como “número de noves”). 
+  Estabeleça seus cenários de falha (por exemplo, perda de um componente, uma zona de disponibilidade ou uma região). 
+  Estabeleça a metodologia de implantação (por exemplo, canário, azul/verde, vermelho/preto ou gradual). 
+  Inclua uma reserva adequada (por exemplo, 15%) do limite atual. 
+  Inclua cálculos para estabilidade estática (por zona e região), quando apropriado. 
+  Planeje o aumento do consumo (por exemplo, monitore suas tendências de consumo). 
+  Considere o impacto da estabilidade estática das suas workloads mais críticas. Avalie os recursos em conformidade com um sistema estaticamente estável em todas as regiões e zonas de disponibilidade. 
+  Considere o uso de reservas de capacidade sob demanda para programas a capacidade antecipadamente de qualquer failover. Isso pode ser uma estratégia útil durante as programações empresariais mais críticas para reduzir possíveis riscos de obter a quantidade o tipo certo de recursos durante o failover. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL01-BP01 Conhecimento das cotas e restrições de serviço](rel_manage_service_limits_aware_quotas_and_constraints.md) 
+  [REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões](rel_manage_service_limits_limits_considered.md) 
+  [REL01-BP03 Acomodar as restrições e as cotas fixas de serviço por meio da arquitetura](rel_manage_service_limits_aware_fixed_limits.md) 
+  [REL01-BP04 Monitorar e gerenciar cotas](rel_manage_service_limits_monitor_manage_limits.md) 
+  [REL01-BP05 Automatizar o gerenciamento de cotas](rel_manage_service_limits_automated_monitor_limits.md) 
+  [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md) 

 **Documentos relacionados:** 
+ [AWS Pilar Confiabilidade da Well-Architected Framework: Disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor Best Practice Checks (Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Service Limits (Limites de serviço))](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS limit monitor on AWS answers](https://aws.amazon.com/answers/account-management/limit-monitor/) (Monitor de limites da AWS em respostas da AWS) 
+  [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) (Limites de serviço do Amazon EC2) 
+  [What is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) (O que é o Service Quotas?) 
+ [ How to Request Quota Increase ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Como solicitar aumento de cota)
+ [ Service endpoints and quotas ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) (Endpoints e cotas de serviço)
+  [Guia do usuário do Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/) (Monitor de cotas da AWS)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [AWS para dados ](https://aws.amazon.com/data/)
+ [ O que significa integração contínua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ O que significa distribuição contínua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/) (Gerenciar o ciclo devida da conta em ambientes de SaaS de conta por locatário na AWS)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/) (Gerenciar e monitorar o controle de utilização de API em workloads)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/) (Exibir recomendações do AWS Trusted Advisor em grande escala com AWS Organizations)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/) (Automatizar aumentos de limite de serviço e suporte empresarial com AWS Control Tower)
+ [Ações, recursos e chaves de condição do Service Quotas](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)

 **Vídeos relacionados:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc) (Exibir e gerenciar cotas para serviços da AWS usando o Service Quotas)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ) (Demonstração de cotas do AWS IAM)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)(AWS re:Invent 2018: fechar ciclos e abrir mentes: como controlar sistemas, sejam grandes ou pequenos)

 **Ferramentas relacionadas:** 
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# CONFIABILIDADE 2. Como planejar sua topologia de rede?
<a name="rel-02"></a>

Muitas vezes, as workloads estão presentes em vários ambientes. Dentre eles estão vários ambientes de nuvem (acessíveis publicamente e privados) e possivelmente sua infraestrutura de datacenter existente. Os planos devem incluir considerações de rede, como conectividade dentro dos sistemas e, entre eles, gerenciamento de endereços IP públicos e privados e resolução de nomes de domínio.

**Topics**
+ [REL02-BP01 Usar conectividade de rede altamente disponível nos endpoints públicos de workload](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 Provisionar conectividade redundante entre as redes privadas na nuvem e nos ambientes on-premises](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 Garantir contas de alocação de sub-rede IP para expansão e disponibilidade](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 Preferir topologias hub-and-spoke em vez da malha muitos para muitos](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 Aplicar intervalos de endereços IP privados não sobrepostos a todos os espaços de endereços privados onde estão conectados](rel_planning_network_topology_non_overlap_ip.md)

# REL02-BP01 Usar conectividade de rede altamente disponível nos endpoints públicos de workload
<a name="rel_planning_network_topology_ha_conn_users"></a>

 Criar uma conectividade de rede altamente disponível nos endpoints públicos das workloads pode ajudar a reduzir o tempo de inatividade devido à perda de conectividade e melhorar a disponibilidade e o SLA da workload. Para que isso seja possível, use DNS altamente disponível, redes de entrega de conteúdo (CDNs), gateways de API, balanceamento de carga ou proxies reversos. 

 **Resultado desejado:** é fundamental planejar, criar e operacionalizar a conectividade de rede altamente disponível para endpoints públicos. Se a workload ficar inacessível devido a uma perda de conectividade, mesmo se ela estiver em execução e indisponível, os clientes verão o sistema como inativo. Ao combinar a conectividade de rede altamente disponível e resiliente para os endpoints públicos da workload, junto com uma arquitetura resiliente para a própria workload, é possível fornecer o melhor nível possível de serviço e disponibilidade possível aos clientes. 

 O AWS Global Accelerator, o Amazon CloudFront, o Amazon API Gateway, os URLs de função do AWS Lambda, as APIs do AWS AppSync e o Elastic Load Balancing (ELB) fornecem endpoints públicos altamente disponíveis. O Amazon Route 53 fornece um serviço de DNS altamente disponível para a resolução do nome de domínio a fim de verificar se os endereços do endpoint público podem ser resolvidos. 

 Também é possível avaliar os dispositivos de software do AWS Marketplace com relação ao proxy e ao balanceamento de carga. 

 **Antipadrões comuns:** 
+ Projetar uma workload altamente disponível sem planejar a alta disponibilidade do DNS e da conectividade de rede.
+  Usar endereços de internet públicos em instâncias ou contêineres individuais e gerenciar a conectividade com eles por meio de DNS.
+  Usar endereços IP em vez de nomes de domínio para localizar serviços.
+  Não testar cenários em que a conectividade com os endpoints públicos é perdida. 
+  Não analisar as necessidades de throughput de rede e os padrões de distribuição. 
+  Não testar nem se planejar para cenários em que a conectividade de rede da internet com os endpoints públicos da workload possam ser interrompidos. 
+  Fornecer conteúdo (como páginas da web, ativos estáticos ou arquivos de mídia) para uma grande área geográfica e não usar uma rede de entrega de conteúdo. 
+  Não se planejar para ataques de negação distribuída de serviços (DDoS). Ataques DDoS representam um risco de obstruir o tráfego legítimo e reduzir a disponibilidade para os usuários. 

 **Benefícios do estabelecimento dessa prática recomendada:** projetar-se para uma conectividade de rede resiliente e altamente disponível garante que a workload esteja acessível e disponível para os usuários. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 No centro da criação de uma conectividade de rede altamente disponível com os endpoints públicos está o roteamento do tráfego. Para verificar se o tráfego consegue acessar os endpoints, o DNS deve poder resolver os nomes de domínio para os endereços IP correspondentes. Use um [Sistema de Nomes de Domínio (DNS)](https://aws.amazon.com/route53/what-is-dns/) escalável e altamente disponível, como o Amazon Route 53, para gerenciar os registros de DNS do domínio. Também é possível usar verificações de integridade fornecidas pelo Amazon Route 53. As verificações de integridade conferem se a aplicação está acessível, disponível e funcional, e podem ser configuradas de uma maneira que imitem o comportamento do usuário, como solicitar uma página da web ou um URL específico. Em caso de falha, o Amazon Route 53 responde às solicitações de resolução de DNS e direciona o tráfego somente aos endpoints íntegros. Também é possível considerar o uso dos recursos DNS GEO e Roteamento baseado em latência oferecidos pelo Amazon Route 53. 

 Para verificar se a própria workload é altamente disponível, use o Elastic Load Balancing (ELB). O Amazon Route 53 pode ser usado para direcionar o tráfego para o ELB, o que distribui o tráfego às instâncias de computação de destino. Também é possível usar o Amazon API Gateway com o AWS Lambda para obter uma solução sem servidor. Os clientes também podem executar workloads em várias Regiões da AWS. Com o [padrão multissite ativo/ativo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/), a workload pode fornecer o tráfego de várias regiões. Com um padrão multissite ativo/passivo, a workload fornece tráfego da região ativa enquanto os dados são replicados para a região secundária e se torna ativa caso ocorra uma falha na região primaria. As verificações de integridade do Route 53 podem então ser usadas para controlar o failover de DNS de qualquer endpoint em uma região primária para um endpoint em uma região secundária, verificando se a workload está acessível e disponível para os usuários. 

 O Amazon CloudFront fornece uma API simples para distribuir o conteúdo com baixa latência e altas taxas de transferência de dados atendendo a solicitações usando uma rede de locais de borda ao redor do mundo. As redes de entrega de conteúdo (CDNs) atendem os clientes fornecendo conteúdo localizado ou armazenado em cache em um local próximo ao usuário. Isso também melhora a disponibilidade da aplicação, já que a carga do conteúdo é migrada dos servidores para os [locais da borda](https://aws.amazon.com/products/networking/edge-networking/) do CloudFront. Os locais da borda e os caches de borda regionais armazenam cópias em cache do conteúdo próximo aos visualizadores, resultando em recuperação rápida e aumentando a acessibilidade e a disponibilidade da workload. 

 Para workloads com usuários distribuídos geograficamente, o AWS Global Accelerator ajuda a melhorar a disponibilidade e o desempenho das aplicações. O AWS Global Accelerator fornece endereços IP estáticos anycast que servem como um ponto de entrada fixo para a aplicação hospedada em uma ou mais Regiões da AWS. Isso permite que o tráfego entre na rede global da AWS o mais próximo possível dos usuários, melhorando a acessibilidade e a disponibilidade da workload. O AWS Global Accelerator também monitora a integridade dos endpoints da aplicação usando as verificações de integridade de TCP, HTTP e HTTPS. Qualquer mudança na integridade ou na configuração dos endpoints aciona o redirecionamento do tráfego de usuários para endpoints íntegros que oferecem o melhor desempenho e disponibilidade aos usuários. Além disso, o AWS Global Accelerator tem um design de isolamento de falhas que usa dois endereços IPv4 estáticos que são fornecidos por zonas de rede independentes, aumentando a disponibilidade das aplicações. 

 Para ajudar a proteger os clientes de ataques DDoS, a AWS oferece o AWS Shield Standard. O Shield Standard vem automaticamente habilitado e protege de ataques de infraestrutura comum (camadas três e quatro) como inundações de SYN/UDP e ataques de reflexão para comportar a alta disponibilidade das aplicações na AWS. Para obter mais proteções contra ataques maiores e mais sofisticados (como inundações de UDP), ataques de exaustão de estado (como inundações de TCP SYN) e para ajudar a proteger as aplicações executadas nos serviços Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator e Route 53, considere o uso do AWS Shield Advanced. Para proteção contra ataques de camada da aplicação como inundações de HTTP POST e GET, use o AWS WAF. O AWS WAF pode usar condições de scripts entre sites, endereços IP, cabeçalhos HTTP, corpo HTTP, strings de URI e injeção de SQL para determinar se uma solicitação deve ser bloqueada ou permitida. 

 **Etapas da implementação** 

1.  Configure DNS de alta disponibilidade: o Amazon Route 53 é um serviço da web de [Sistema de Nomes de Domínio (DNS)](https://aws.amazon.com/route53/what-is-dns/) escalável e altamente disponível. O Route 53 conecta as solicitações dos usuários às aplicações da internet executadas na AWS ou on-premises. Para obter mais informações, consulte [Configurar o Amazon Route 53 como serviço DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html). 

1.  Configure verificações de integridade: ao usar o Route 53, verifique se somente os destinos íntegros podem ser resolvidos. Comece [criando verificações de integridade do Route 53 e configurando o failover de DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html). Os aspectos a seguir são importantes a considerar ao configurar verificações de integridade: 

   1. [ How Amazon Route 53 determines whether a health check is healthy ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html)(Como o Amazon Route 53 determina se uma verificação de integridade é íntegra)

   1. [ Criar, atualizar e excluir verificações de integridade ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html)

   1. [ Monitorar o status da verificação de integridade e receber notificações ](https://docs.aws.amazon.com/)

   1. [ Práticas recomendadas do Amazon Route 53 DNS ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html)

1. [ Conectar o serviço de DNS aos endpoints. ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html)

   1.  Ao usar o Elastic Load Balancing como destino do tráfego, crie um [registro de alias](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) usando o Amazon Route 53 que aponte para o endpoint regional do balanceador de carga. Durante a criação do registro de alias, defina a opção “Evaluate target health” (Avaliar integridade do destino) como “Yes” (Sim). 

   1.  Para workloads sem servidor ou APIs privadas quando o API Gateway é usado, use o [Route 53 para redirecionar o tráfego para o API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html). 

1.  Decida sobre uma rede de entrega de conteúdo. 

   1.  Para entregar conteúdo usando locais da borda mais próximos ao usuário, comece entendendo [como o CloudFront entrega conteúdo](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html). 

   1.  Comece com uma [distribuição simples do CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.SimpleDistribution.html). O CloudFront então sabe de onde você quer que o conteúdo seja entregue e os detalhes sobre como rastrear e gerenciar a entrega de conteúdo. É importante entender e considerar os aspectos a seguir ao configurar uma distribuição do CloudFront: 

      1. [ Como funciona o armazenamento em cache com os pontos de presença do CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio-explained.html)

      1. [ Aumentar a taxa de solicitações fornecidas diretamente de caches do CloudFront (taxa de acertos do cache) ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html)

      1. [ Usar o Amazon CloudFront Origin Shield ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html)

      1. [ Otimizar a alta disponibilidade com o failover de origem do CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)

1.  Configure a proteção da camada da aplicação: o AWS WAF ajuda você a se proteger contra explorações e bots comuns da web que podem afetar a disponibilidade, comprometer a segurança ou consumir recursos em excesso. Para obter uma compreensão mais profunda, veja [como o AWS WAF funciona](https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html) e, quando estiver pronto para implementar proteções contra inundações HTTP POST E GET da camada de aplicações, consulte [Getting started with AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) (Conceitos básicos do AWS WAF). Também é possível usar o AWS WAF com o CloudFront. Consulte a documentação sobre [como o AWS WAF funciona com os recursos do Amazon CloudFront](https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html). 

1.  Configure proteção adicional contra DDoS: por padrão, todos os clientes da AWS recebem proteção contra ataques de DDoS da camada de transporte e rede comuns e que ocorrem com mais frequência que visam seu site ou sua aplicação com o AWS Shield Standard sem custo adicional. Para proteção adicional de aplicações voltadas para a internet executadas no Amazon EC2, Elastic Load Balancing, Amazon CloudFront, AWS Global Accelerator e Amazon Route 53, considere o [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html) e consulte [exemplos de arquiteturas resilientes a DDoS](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-resiliency.html). Para proteger sua workload e seus endpoints públicos de ataques de DDoS, consulte [Getting started with AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-ddos.html) (Conceitos básicos do AWS Shield Advanced). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md) 
+  [REL10-BP02 Escolher os locais apropriados para sua implantação de vários locais](rel_fault_isolation_select_location.md) 
+  [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md) 
+  [REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade](rel_withstand_component_failures_notifications_sent_system.md) 

 **Documentos relacionados:** 
+  [Parceiro do APN: parceiros que podem ajudar a planejar sua rede](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace para infraestrutura de rede](https://aws.amazon.com/marketplace/b/2649366011) 
+  [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 
+  [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 
+  [O que é o Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
+  [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 
+ [ Network Connectivity capability - Establishing Your Cloud Foundations ](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/network-connectivity-capability.html)(Recurso de conectividade de rede: como estabelecer as bases da nuvem)
+ [ O que é o Amazon API Gateway? ](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
+ [ What are AWS WAF, AWS Shield, and AWS Firewall Manager? ](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html)(O que são o AWS WAF, o AWS Shield e o AWS Firewall Manager?)
+ [ O que é o Amazon Route 53 Application Recovery Controller? ](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [ Configurar verificações de integridade personalizadas para failover de DNS ](https://docs.aws.amazon.com/apigateway/latest/developerguide/dns-failover.html)

 **Vídeos relacionados:** 
+ [AWS re:Invent 2022 - Improve performance and availability with AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)(AWS re:Invent 2022: melhore o desempenho e a disponibilidade com o AWS Global Accelerator)
+ [AWS re:Invent 2020: Global traffic management with Amazon Route 53 ](https://www.youtube.com/watch?v=E33dA6n9O7I)(AWS re:Invent 2020: gerenciamento de tráfego global com o Amazon Route 53)
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications ](https://www.youtube.com/watch?v=mwUV5skJJ0s)(AWS re:Invent 2022: operar aplicações Multi-AZ altamente disponíveis)
+ [AWS re:Invent 2022 - Dive deep on AWS networking infrastructure ](https://www.youtube.com/watch?v=HJNR_dX8g8c)(AWS re:Invent 2022: aprofundamento na infraestrutura de rede da AWS)
+ [AWS re:Invent 2022 - Building resilient networks ](https://www.youtube.com/watch?v=u-qamiNgH7Q)(AWS re:Invent 2022: criar redes resilientes)

 **Exemplos relacionados:** 
+ [ Disaster Recovery with Amazon Route 53 Application Recovery Controller (ARC) ](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)(Recuperação de desastres com o Amazon Route 53 Application Recovery Controller (ARC))
+ [ Reliability Workshops ](https://wellarchitectedlabs.com/reliability/)(Workshops sobre confiabilidade)
+ [Workshop sobre o AWS Global Accelerator](https://catalog.us-east-1.prod.workshops.aws/workshops/effb1517-b193-4c59-8da5-ce2abdb0b656/en-US)

# REL02-BP02 Provisionar conectividade redundante entre as redes privadas na nuvem e nos ambientes on-premises
<a name="rel_planning_network_topology_ha_conn_private_networks"></a>

 Use várias conexões do AWS Direct Connect ou túneis VPN entre as redes privadas implantadas separadamente. Use vários locais do Direct Connect para alta disponibilidade. Se estiver usando várias Regiões da AWS, garanta a redundância em pelo menos duas delas. Você pode avaliar os appliances do AWS Marketplace que encerram as VPNs. Se você usa appliances do AWS Marketplace, implante instâncias redundantes em zonas de disponibilidade diferentes para alta disponibilidade. 

 O AWS Direct Connect é um serviço de nuvem que facilita a criação de uma conexão de rede dedicada entre seu ambiente on-premises e a AWS. Usando o Direct Connect Gateway, seu datacenter on-premises pode ser conectado a várias VPCs da AWS distribuídas em várias Regiões da AWS. 

 Essa redundância resolve possíveis falhas que afetam a resiliência da conectividade: 
+  Como você será resiliente a falhas em sua topologia? 
+  O que acontecerá se você configurar algo incorretamente e remover a conectividade? 
+  Você será capaz de lidar com um aumento inesperado no tráfego ou uso de seus serviços? 
+  Você conseguirá absorver uma tentativa de ataque de Negação de serviço distribuída (DDoS)? 

 Ao conectar sua VPC ao seu datacenter on-premises por meio de uma VPN, considere a resiliência e a largura de banda necessárias ao selecionar o fornecedor e o tamanho da instância em que precisa executar o dispositivo. Se você usar um dispositivo de VPN que não seja resiliente nesta implementação, precisará ter uma conexão redundante por meio de um segundo dispositivo. Para todos esses cenários, é preciso definir um tempo aceitável para recuperação e testar para garantir que você consiga cumprir esses requisitos. 

 Se você optar por conectar a VPC ao datacenter usando uma conexão Direct Connect e precisar que essa conexão seja altamente disponível, tenha conexões Direct Connect redundantes provenientes de cada datacenter. A conexão redundante deve usar uma segunda conexão Direct Connect de um local diferente do primeiro. Se você tiver vários datacenters, garanta que as conexões terminem em diferentes locais. Use a ferramenta de recomendações do [Toolkit de resiliência do Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) para ajudar a configurar isso. 

 Se você escolher fazer failover para a VPN pela Internet usando a Site-to-Site VPN, saiba que ela é compatível com um throughput de até 1,25 Gbps por túnel VPN, mas não é compatível com Múltiplos caminhos de mesmo custo (ECMP) para tráfego de saída no caso de vários túneis da AWS Managed VPN terminarem no mesmo VGW. Não recomendamos que você use o AWS Managed VPN como backup para conexões Direct Connect, a menos que possa tolerar velocidades inferiores a 1 Gbps durante o failover. 

 Você também pode usar endpoints da VPC para conectar sua VPC a serviços compatíveis da AWS e do endpoint da VPC alimentado pelo AWS PrivateLink sem passar pela Internet pública. Os endpoints são dispositivos virtuais. Eles são componentes de VPC altamente disponíveis, redundantes e escalados horizontalmente. Eles permitem a comunicação entre instâncias em sua VPC e serviços sem impor riscos de disponibilidade ou restrições de largura de banda ao tráfego de rede. 

 **Antipadrões comuns:** 
+  Ter apenas um provedor de conectividade entre a rede local e a AWS. 
+  Consumir os recursos de conectividade da conexão do AWS Direct Connect, mas ter apenas uma conexão. 
+  Ter apenas um caminho para conectividade VPN. 

 **Benefícios do estabelecimento dessa prática recomendada:** Ao implementar conectividade redundante entre seu ambiente de nuvem e o ambiente corporativo ou on-premises, você pode garantir que os serviços dependentes entre os dois ambientes possam se comunicar de forma confiável. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Verifique se você tem conectividade altamente disponível entre a AWS e o ambiente on-premises. Use várias conexões do AWS Direct Connect ou túneis VPN entre as redes privadas implantadas separadamente. Use vários locais do Direct Connect para alta disponibilidade. Se estiver usando várias Regiões da AWS, garanta a redundância em pelo menos duas delas. Você pode avaliar os appliances do AWS Marketplace que encerram as VPNs. Se você usa appliances do AWS Marketplace, implante instâncias redundantes em zonas de disponibilidade diferentes para alta disponibilidade. 
  +  Verifique se você tem uma conexão redundante com seu ambiente on-premises. Você pode precisar de conexões redundantes para várias Regiões da AWS para atender às necessidades de disponibilidade. 
    +  [Recomendações de resiliência do AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/) 
    +  [Uso de conexões Site-to-Site VPN redundantes para fornecer failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) 
      +  Use as operações de API de serviço para identificar o uso correto dos circuitos do Direct Connect. 
        +  [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html) 
        +  [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html) 
        +  [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html) 
        +  [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll) 
        +  [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html) 
        +  [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html) 
        +  [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html) 
      +  Se houver apenas uma conexão Direct Connect ou se você não tiver nenhuma, configure túneis VPN redundantes para seus gateways privados virtuais. 
        +  [O que é a AWS Site-to-Site VPN?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html) 
  +  Capture a conectividade atual (por exemplo, Direct Connect, gateways privados virtuais, dispositivos do AWS Marketplace). 
    +  Use as operações de API de serviço para consultar a configuração das conexões Direct Connect. 
      +  [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html) 
      +  [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html) 
      +  [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html) 
      +  [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll) 
      +  [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html) 
      +  [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html) 
      +  [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html) 
    +  Use as operações de API de serviço para coletar gateways privados virtuais onde as tabelas de rotas os usam. 
      +  [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html) 
      +  [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) 
    +  Use as operações de API de serviço para coletar aplicações do AWS Marketplace onde as tabelas de rotas as utilizam. 
      +  [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro do APN: parceiros que podem ajudar a planejar sua rede](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [Recomendações de resiliência do AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/) 
+  [AWS Marketplace para infraestrutura de rede](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Whitepaper sobre as opções de conectividade do Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Uso de conexões Site-to-Site VPN redundantes para fornecer failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) 
+  [Usar o Toolkit de resiliência do Direct Connect para começar](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) 
+  [VPC endpoints e serviços de VPC endpoint (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 
+  [O que é o Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [O que é um Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
+  [O que é a AWS Site-to-Site VPN?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html) 
+  [Trabalho com gateways Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP03 Garantir contas de alocação de sub-rede IP para expansão e disponibilidade
<a name="rel_planning_network_topology_ip_subnet_allocation"></a>

 Intervalos de endereços IP da Amazon VPC devem ser grandes o suficiente para acomodar os requisitos da workload, incluindo a futura expansão e alocação de endereços IP para sub-redes nas zonas de disponibilidade. Isso inclui load balancers, instâncias do EC2 e aplicativos baseados em contêiner. 

 Ao planejar sua topologia de rede, a primeira etapa é definir o espaço do endereço IP em si. Intervalos de endereços IP privados (seguindo as diretrizes RFC 1918) devem ser alocados para cada VPC. Atenda aos seguintes requisitos como parte desse processo: 
+  Permitir espaço de endereço IP para mais de uma VPC por região. 
+  Dentro de uma VPC, deixe espaço para várias sub-redes que abrangem várias zonas de disponibilidade. 
+  Sempre deixe o espaço de bloco CIDR não utilizado em uma VPC para futura expansão. 
+  Verifique se há espaço de endereço IP para atender às necessidades de qualquer frota transitória de instâncias do EC2 que você use, como frotas spot para machine learning, clusters do Amazon EMR ou clusters do Amazon Redshift. 
+  Observe que os primeiros quatro endereços IP e o último endereço IP em cada bloco CIDR da sub-rede estão reservados e não estão disponíveis para seu uso. 
+  Você deve planejar implantar grandes blocos CIDR de VPC. Observe que o bloco CIDR inicial da VPC alocado para sua VPC não pode ser alterado ou excluído, mas você pode adicionar blocos CIDR não sobrepostos à VPC. Os CIDRs IPv4 da sub-rede não podem ser alterados, mas os CIDRs IPv6 podem. Lembre-se de que implantar a maior VPC possível (/16) resulta em mais de 65 mil endereços IP. Somente no espaço de endereço IP 10.x.x.x, você pode provisionar 255 dessas VPCs. Portanto, você deve errar por ser muito grande em vez de muito pequeno para facilitar o gerenciamento de suas VPCs. 

 **Antipadrões comuns:** 
+  Criar VPCs pequenas. 
+  Criar sub-redes pequenas e ter de adicionar sub-redes às configurações à medida que você cresce. 
+  Estimar incorretamente quantos endereços IP um Elastic Load Balancer pode usar. 
+  Implantar muitos load balancers de alto tráfego nas mesmas sub-redes. 

 **Benefícios do estabelecimento dessa prática recomendada:** Isso garante que você possa acomodar o crescimento das suas cargas de trabalho e continuar a fornecer disponibilidade à medida que elas se expandem. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Planeje sua rede para acomodar crescimento, conformidade regulamentar e integração com outras pessoas. O crescimento pode ser subestimado, a conformidade regulamentar pode mudar e as aquisições ou conexões de rede privada podem ser difíceis de implementar sem o planejamento adequado. 
  +  Selecione as Contas da AWS e regiões relevantes conforme seus requisitos de serviço, de latência, regulatórios e de recuperação de desastres (DR). 
  +  Identifique suas necessidades para implantações regionais de VPC. 
  +  Identifique o tamanho das VPCs. 
    +  Determine se você pretende implantar conectividade com várias VPCs. 
      +  [O que é um Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
      +  [Conectividade com várias VPCs de região única](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) 
    +  Determine se você precisa de rede segregada por requisitos regulamentares. 
    +  Faça VPCs o maior possível. O bloco CIDR inicial da VPC alocado para sua VPC não pode ser alterado ou excluído, mas você pode adicionar outros blocos CIDR não sobrepostos à VPC. No entanto, isso pode fragmentar seus intervalos de endereços. 
    +  Faça VPCs o maior possível. O bloco CIDR inicial da VPC alocado para sua VPC não pode ser alterado ou excluído, mas você pode adicionar outros blocos CIDR não sobrepostos à VPC. No entanto, isso pode fragmentar seus intervalos de endereços. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro do APN: parceiros que podem ajudar a planejar sua rede](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace para infraestrutura de rede](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Whitepaper sobre as opções de conectividade do Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Conectividade com várias VPCs de região única](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) 
+  [O que é o Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP04 Preferir topologias hub-and-spoke em vez da malha muitos para muitos
<a name="rel_planning_network_topology_prefer_hub_and_spoke"></a>

 Se mais de dois espaços de endereço de rede (por exemplo, VPCs e redes on-premises) estiverem conectados por meio do emparelhamento de VPC, do AWS Direct Connect ou da VPN, use um modelo hub-and-spoke, como o fornecido pelo AWS Transit Gateway. 

 Se você tiver apenas duas redes desse tipo, basta conectá-las uma à outra, mas à medida que o número de redes cresce, a complexidade dessas conexões de malha torna-se insustentável. O AWS Transit Gateway oferece um modelo hub-and-spoke fácil de manter, permitindo o roteamento de tráfego em várias redes. 

![\[Diagrama mostrando o não uso do AWS Transit Gateway\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/without-transit-gateway.png)


![\[Diagrama mostrando o uso do AWS Transit Gateway\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/with-transit-gateway.png)


 **Antipadrões comuns:** 
+  Usar o emparelhamento de VPC para conectar mais de duas VPCs. 
+  Estabelecer várias sessões de BGP a cada VPC para fornecer conectividade que abrange as nuvens privadas virtuais (VPCs) distribuídas em diversas Regiões da AWS. 

 **Benefícios do estabelecimento dessa prática recomendada:** À medida que o número de redes cresce, a complexidade dessas conexões em malha torna-se insustentável. O AWS Transit Gateway oferece um modelo hub-and-spoke fácil de manter, que permite o roteamento do tráfego entre várias redes. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Prefira topologias hub-and-spoke em vez da malha muitos para muitos. Se mais de dois espaços de endereço de rede (por exemplo, VPCs e redes on-premises) estiverem conectados por meio do emparelhamento de VPC, do AWS Direct Connect ou da VPN, use um modelo hub-and-spoke, como o fornecido pelo AWS Transit Gateway. 
  +  Para apenas duas redes desse tipo, você pode simplesmente conectá-las uma à outra. No entanto, à medida que o número de redes cresce, a complexidade dessas conexões em malha torna-se insustentável. O AWS Transit Gateway oferece um modelo hub-and-spoke fácil de manter, que permite o roteamento do tráfego entre várias redes. 
    +  [O que é um Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro do APN: parceiros que podem ajudar a planejar sua rede](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace para infraestrutura de rede](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [VPC endpoints e serviços de VPC endpoint (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 
+  [O que é o Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [O que é um Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP05 Aplicar intervalos de endereços IP privados não sobrepostos a todos os espaços de endereços privados onde estão conectados
<a name="rel_planning_network_topology_non_overlap_ip"></a>

 Os intervalos de endereços IP de cada uma das suas VPCs não devem se sobrepor quando emparelhados ou conectados por VPN. Você deve evitar conflitos de endereço IP da mesma forma entre uma VPC e ambientes no local ou com outros provedores de nuvem que você usa. Você também deve ter uma maneira de alocar intervalos de endereços IP privados quando necessário. 

 Um sistema de gerenciamento de endereços IP (IPAM) pode ajudar com isso. Vários IPAMs estão disponíveis no AWS Marketplace. 

 **Antipadrões comuns:** 
+  Usar o mesmo intervalo de IPs na VPC que você tem no local ou na rede corporativa. 
+  Não acompanhar os intervalos IPs das VPCs usadas para implantar suas cargas de trabalho. 

 **Benefícios do estabelecimento dessa prática recomendada:** O planejamento ativo da rede garantirá que você não tenha várias ocorrências do mesmo endereço IP nas redes interconectadas. Isso evita que problemas de roteamento ocorram em partes da carga de trabalho que usam os diferentes aplicativos. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Monitore e gerencie seu uso do CIDR. Avalie seu uso potencial na AWS, adicione intervalos de CIDR às VPCs existentes e crie VPCs para permitir um crescimento planejado no uso. 
  +  Capture o consumo atual do CIDR (por exemplo, VPCs, sub-redes etc.) 
    +  Use as operações de API de serviço para coletar o consumo atual do CIDR. 
  +  Capture o seu uso atual de sub-rede. 
    +  Use as operações de API de serviço para coletar sub-redes por VPC em cada região. 
      +  [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html) 
    +  Registre o uso atual. 
    +  Determine se você criou algum intervalos de IP sobrepostos. 
    +  Calcule a capacidade não utilizada. 
    +  Identifique intervalos de IP sobrepostos. Você pode migrar para um novo intervalo de endereços ou usar os dispositivos de tradução de rede e porta (NAT) do AWS Marketplace se precisar conectar os intervalos sobrepostos. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro do APN: parceiros que podem ajudar a planejar sua rede](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace para infraestrutura de rede](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Whitepaper sobre as opções de conectividade do Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [O que é o Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [O que é o IPAM?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# Arquitetura da carga de trabalho
<a name="a-workload-architecture"></a>

**Topics**
+ [CONFIABILIDADE 3. Como projetar sua arquitetura de serviços de workload?](rel-03.md)
+ [CONFIABILIDADE 4. Como projetar interações em um sistema distribuído para evitar falhas?](rel-04.md)
+ [CONFIABILIDADE 5. Como projetar interações em um sistema distribuído para mitigar ou resistir a falhas?](rel-05.md)

# CONFIABILIDADE 3. Como projetar sua arquitetura de serviços de workload?
<a name="rel-03"></a>

Use uma Service-Oriented Architecture (SOA – Arquitetura orientada por serviços) ou uma arquitetura de microsserviços para criar cargas de trabalho altamente escaláveis e confiáveis. A SOA é a prática de tornar componentes de software reutilizáveis por meio de interfaces de serviço. A arquitetura de microsserviços vai além para tornar os componentes menores e mais simples.

**Topics**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Criar serviços enfocados em domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornecer contratos de serviço por API](rel_service_architecture_api_contracts.md)

# REL03-BP01 Escolher como segmentar a workload
<a name="rel_service_architecture_monolith_soa_microservice"></a>

 A segmentação de workloads é importante ao determinar os requisitos de resiliência de sua aplicação. Uma arquitetura monolítica deve ser evitada sempre que possível. Em vez disso, considere cuidadosamente quais componentes da aplicação podem ser distribuídos em microsserviços. Dependendo dos requisitos de sua aplicação, isso pode acabar sendo uma combinação de uma arquitetura orientada a serviços (SOA) com microsserviços sempre que possível. Workloads com capacidade para serem do tipo sem estado têm maior chance de serem implantadas como microsserviços. 

 **Resultado desejado:** as workloads devem ser compatíveis, escaláveis e o mais vagamente agrupadas possível. 

 Ao tomar decisões sobre como segmentar uma workload, pondere os benefícios e as complexidades. O que é ideal para um novo produto a caminho do seu primeiro lançamento não se aplica a uma workload que foi criada para escalabilidade a partir das necessidades iniciais. Ao refatorar um monólito existente, você vai precisar considerar o quanto a aplicação vai oferecer um bom suporte a uma decomposição em direção à condição sem estado. A divisão dos serviços em pedaços menores permite que equipes pequenas e bem definidas os desenvolvam e gerenciem. No entanto, serviços menores podem introduzir complexidades que incluem maior latência potencial, depuração mais complexa e carga operacional aumentada. 

 **Antipadrões comuns:** 
+  O [microsserviço *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) é uma situação em que os componentes atômicos se tornam tão altamente interdependentes que a falha de um resulta em uma falha muito maior, o que torna os componentes tão rígidos e frágeis quanto um monólito. 

 **Benefícios do estabelecimento desta prática:** 
+  Mais segmentos específicos geram maior agilidade, flexibilidade organizacional e escalabilidade. 
+  Redução do impacto das interrupções do serviço. 
+  Os componentes da aplicação podem ter requisitos de disponibilidade diferentes, aos quais uma segmentação mais atômica pode oferecer suporte. 
+  Responsabilidades bem definidas para as equipes que oferecem suporte à workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Escolha o tipo de arquitetura com base no modo como você segmentará a workload. Escolha uma SOA ou arquitetura de microsserviços (ou, em alguns casos, uma arquitetura monolítica). Mesmo que você opte por começar com uma arquitetura monolítica, você deve garantir que ela seja modular e tenha a capacidade de evoluir para SOA ou microsserviços à medida que o produto escala com a adoção do usuário. A SOA e os microsserviços oferecem, respectivamente, segmentação menor, que é preferida como uma arquitetura moderna escalável e confiável, mas há compensações a serem consideradas, especialmente ao implantar uma arquitetura de microsserviços. 

 Uma compensação primária é que você agora tem uma arquitetura de computação distribuída que pode tornar mais difícil alcançar requisitos de latência do usuário final, e há complexidade adicional na depuração e no rastreamento de interações com o usuário. Use o AWS X-Ray para ajudar você a resolver esse problema. Outro efeito a ser considerado é o aumento da complexidade operacional à medida que você aumenta o número de aplicações que está gerenciando, o que requer a implantação de vários componentes de independência. 

![\[Diagrama de comparação entre arquiteturas monolítica, orientada a serviços e de microsserviços\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/monolith-soa-microservices-comparison.png)


## Etapas da implementação
<a name="implementation-steps"></a>
+  Determine a arquitetura adequada para refatorar ou desenvolver sua aplicação. A SOA e os microsserviços oferecem respectivamente segmentação menor, que é preferida por ser uma arquitetura moderna escalável e confiável. A SOA pode ser o meio-termo ideal para alcançar uma segmentação menor e também evitar algumas das complexidades dos microsserviços. Para obter mais detalhes, consulte [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html). 
+  Se sua carga de trabalho aceitá-la e sua organização puder sustentá-la, use uma arquitetura de microsserviços para obter a melhor agilidade e confiabilidade. Para obter mais detalhes, consulte [Implementação de microsserviços na AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  Considere seguir o [*padrão* Strangler Fig](https://martinfowler.com/bliki/StranglerFigApplication.html) para refatorar um monólito em componentes menores. Isso envolve a substituição gradual de componentes específicos da aplicação por novas aplicações e serviços. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) atua como um ponto de partida para refatoração incremental. Para obter mais detalhes, consulte [Migração simplificada de workloads on-premises herdadas usando um padrão strangler](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/). 
+  A implementação de microsserviços pode exigir um mecanismo de descoberta de serviços para permitir que esses serviços distribuídos se comuniquem entre si. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) pode ser usado com arquiteturas orientadas por serviços para fornecer descoberta confiável e acesso a serviços. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) também pode ser usado para descoberta dinâmica de serviços baseada em DNS. 
+  Se você estiver migrando de um monólito para SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) pode ajudar a eliminar a lacuna como um barramento de serviço ao reprojetar aplicações herdadas na nuvem.
+  Para monólitos existentes com um único banco de dados compartilhado, escolha como reorganizar os dados em segmentos menores. Isso pode acontecer por unidade de negócios, padrão de acesso ou estrutura de dados. A esta altura no processo de refatoração, escolha se deseja prosseguir com um banco de dados relacional ou não relacional (NoSQL). Para obter mais detalhes, consulte [De SQL para NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html). 

 **Nível de esforço do plano de implementação:** Alto 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL03-BP02 Criar serviços enfocados em domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md) 

 **Documentos relacionados:** 
+  [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [O que é arquitetura orientada a serviços?](https://aws.amazon.com/what-is/service-oriented-architecture/) 
+  [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html) 
+  [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html) 
+  [Microsserviços - uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html) 
+  [Microsserviços na AWS](https://aws.amazon.com/microservices/) 
+  [O que é o AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) 

 **Exemplos relacionados:** 
+  [Workshop de modernização iterativa de aplicações](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro) 

 **Vídeos relacionados:** 
+  [Delivering Excellence with Microservices on AWS (Entregando excelência com microsserviços na AWS)](https://www.youtube.com/watch?v=otADkIyugzY) 

# REL03-BP02 Criar serviços enfocados em domínios e funcionalidades de negócios específicos
<a name="rel_service_architecture_business_domains"></a>

A arquitetura orientada a serviços (SOA) define serviços com funções bem delineadas que seguem as necessidades dos negócios. Os microsserviços usam modelos de domínio e contexto delimitado para traçar limites de serviço ao longo dos limites do contexto de negócios. O foco nos domínios de negócios e na funcionalidade ajuda as equipes a definir requisitos independentes de confiabilidade para seus serviços. Contextos delimitados isolam e encapsulam a lógica de negócios, permitindo que as equipes raciocinem melhor sobre como lidar com falhas.

 **Resultado desejado:** Em conjunto, engenheiros e partes interessadas do negócio definem contextos delimitados e os usam para projetar sistemas como serviços que cumprem funções empresariais específicas. Essas equipes usam práticas estabelecidas, como Event Storming, para definir os requisitos. As novas aplicações são projetadas como serviços, limites bem definidos e acoplamento fraco. Os monólitos existentes são decompostos em [contextos delimitados](https://martinfowler.com/bliki/BoundedContext.html) e os projetos de sistemas migram para arquiteturas SOA ou de microsserviços. Quando os monólitos são refatorados, abordagens estabelecidas, como contextos de bolha e padrões de decomposição de monólitos, são aplicadas. 

 Os serviços orientados a domínios são executados como um ou mais processos que não compartilham o estado. Eles respondem de forma independente às flutuações na demanda e lidam com cenários de falha à luz dos requisitos específicos do domínio. 

 **Antipadrões comuns:** 
+  As equipes são formadas em torno de domínios técnicos específicos, como UI e UX, middleware ou banco de dados, em vez de domínios empresariais específicos. 
+  As aplicações abrangem as responsabilidades do domínio. Serviços que abrangem contextos delimitados podem ser mais difíceis de manter, exigir maiores esforços de teste e que várias equipes de domínio participem das atualizações de software. 
+  As dependências de domínio, como as bibliotecas de entidades de domínio, são compartilhadas entre serviços, de forma que as alterações em um domínio de serviço exijam alterações em outros domínios de serviço. 
+  Os contratos de serviço e a lógica de negócios não expressam entidades em uma linguagem de domínio comum e consistente, ocasionando camadas de tradução que complicam os sistemas e aumentam os esforços de depuração. 

 **Benefícios de estabelecer esta prática recomendada:** As aplicações são projetadas como serviços independentes delimitados por domínios de negócios e usam uma linguagem comercial comum. Os serviços podem ser testados e implantados de forma independente. Os serviços atendem aos requisitos de resiliência específicos do domínio implementado. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A decisão orientada por domínio (DDD) é a abordagem fundamental para projetar e criar software em torno de domínios empresariais. É útil trabalhar com uma framework existente ao criar serviços enfocados em domínios empresariais. Ao trabalhar com aplicações monolíticas existentes, você pode utilizar os padrões de decomposição que fornecem técnicas estabelecidas para modernizar aplicações em serviços. 

![\[Fluxograma descrevendo a abordagem da decisão orientada por domínio.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/domain-driven-decision.png)


 

## Etapas da implementação
<a name="implementation-steps"></a>
+  As equipes podem realizar workshops de [Event Storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming) a fim de identificar rapidamente eventos, comandos, agregados e domínios em um formato leve de notas adesivas. 
+  Depois que as entidades e as funções do domínio forem formadas em um contexto de domínio, você poderá dividir seu domínio em serviços usando [contexto delimitado](https://martinfowler.com/bliki/BoundedContext.html), em que entidades que compartilham recursos e atributos semelhantes são agrupadas. Com o modelo dividido em contextos, surge um modelo de como delimitar microsserviços. 
  +  Por exemplo, as entidades do site Amazon.com podem incluir pacote, entrega, programação, preço, desconto e moeda. 
  +  Pacote, entrega e cronograma são agrupados no contexto de envio, enquanto preço, desconto e moeda são agrupados no contexto de preços. 
+  [Decompor monólitos em microsserviços](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) descreve padrões para refatorar microsserviços. O uso de padrões para decomposição por capacidade comercial, subdomínio ou transação se alinha bem às abordagens orientadas por domínio. 
+  Técnicas táticas, como o [contexto de bolha,](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) permitem introduzir o DDD em aplicações existentes ou legadas sem reformulações antecipadas e compromissos totais com o DDD. Em uma abordagem de contexto de bolha, um pequeno contexto delimitado é estabelecido usando um mapeamento e coordenação de serviços, ou [camada anticorrupção](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context), que protege o modelo de domínio recém-definido de influências externas. 

 Depois que as equipes realizarem a análise de domínio e definirem entidades e contratos de serviço, elas podem utilizar os serviços da AWS para implementar o design orientado por domínio como serviços baseados em nuvem. 
+  Comece o desenvolvimento definindo testes que exercitem as regras de negócios de seu domínio. O desenvolvimento orientado por testes (TDD) e o desenvolvimento orientado por comportamento (BDD) ajudam as equipes a manter os serviços enfocados na solução de problemas de negócios. 
+  Selecione os [serviços da AWS](https://aws.amazon.com/microservices/) que mais bem atendam aos requisitos de domínio de sua empresa e [arquitetura de microsserviços](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html): 
  +  [tecnologia sem servidor da AWS](https://aws.amazon.com/serverless/) permite que sua equipe enfoque a lógica de domínio específica em vez de gerenciar servidores e infraestrutura. 
  +  [Contêineres na AWS](https://aws.amazon.com/containers/) simplificam o gerenciamento de sua infraestrutura para que você possa enfocar nos requisitos de domínio. 
  +  [Bancos de dados com propósito específico](https://aws.amazon.com/products/databases/) ajudam você a adequar seus requisitos de domínio ao tipo de banco de dados mais adequado. 
+  [Criação de arquiteturas hexagonais na AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) descreve uma framework para criar lógica de negócios em serviços que funcionam retroativamente a partir de um domínio empresarial para atender aos requisitos funcionais e, depois, conectar adaptadores de integração. Os padrões que separam os detalhes da interface da lógica de negócios com serviços da AWS ajudam as equipes a enfocar na funcionalidade do domínio e melhorar a qualidade do software. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL03-BP03 Fornecer contratos de serviço por API](rel_service_architecture_api_contracts.md) 

 **Documentos relacionados:** 
+ [AWS Microsserviços](https://aws.amazon.com/microservices/)
+  [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [How to break a Monolith into Microservices (Como dividir um monólito em microsserviços)](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
+  [Getting Started with DDD when Surrounded by Legacy Systems (Conceitos básicos do DDD quando cercado por sistemas herdados)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
+ [ Domain-Driven Design: Tackling Complexity in the Heart of Software (Design orientado por domínio: como lidar com a complexidade no núcleo do software) ](https://www.amazon.com/gp/product/0321125215)
+ [ Criação de arquiteturas hexagonais na AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Decompor monólitos em microsserviços ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [ Event Storming ](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [ Mensagens entre contextos delimitados ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Microsserviços ](https://www.martinfowler.com/articles/microservices.html)
+ [ Desenvolvimento orientado por testes ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Desenvolvimento orientado pelo comportamento ](https://en.wikipedia.org/wiki/Behavior-driven_development)

 **Exemplos relacionados:** 
+ [ Workshop nativo da nuvem corporativa ](https://catalog.us-east-1.prod.workshops.aws/workshops/0466c70e-4216-4352-98d9-5a8af59c86b2/en-US)
+ [ Designing Cloud Native Microservices on AWS (from DDD/EventStormingWorkshop) (Como projetar microsserviços nativos em nuvem na AWS (do DDD/EventStormingWorkshop)) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)

 **Ferramentas relacionadas:** 
+ [ Bancos de dados da Nuvem AWS](https://aws.amazon.com/products/databases/)
+ [ Tecnologia sem servidor na AWS](https://aws.amazon.com/serverless/)
+ [ Contêineres na AWS](https://aws.amazon.com/containers/)

# REL03-BP03 Fornecer contratos de serviço por API
<a name="rel_service_architecture_api_contracts"></a>

Os contratos de serviço são acordos documentados entre produtores e consumidores de API estabelecidos em uma definição de API legível por máquina. Uma estratégia de versionamento de contrato permite que os consumidores continuem usando a API existente e migrem suas aplicações para uma API mais recente quando estiverem prontos. A implantação do produtor pode acontecer a qualquer momento, desde que o contrato seja cumprido. A equipe de serviços pode usar a pilha de tecnologia de sua preferência para cumprir o contrato de API. 

 **Resultado desejado:** 

 **Antipadrões comuns:** As aplicações criadas com arquiteturas orientadas a serviços ou microsserviços podem operar de forma independente e, ao mesmo tempo, ter uma dependência de runtime integrada. As alterações implantadas em um consumidor ou produtor de API não interrompem a estabilidade do sistema geral quando os dois lados seguem um contrato de API comum. Os componentes que se comunicam por meio de APIs de serviço podem realizar lançamentos funcionais independentes, atualizações para dependências de runtime ou fazer failover em um site de recuperação de desastres (DR) com pouco ou nenhum impacto entre si. Além disso, serviços diferentes são capazes de escalar de forma independente a absorção da demanda de recursos sem exigir que outros serviços escalem simultaneamente. 
+  Criar APIs de serviço sem esquemas altamente tipificados. Isso ocasiona APIs que não podem ser usadas para gerar vinculações de API e payloads que não possam ser validadas de maneira programática. 
+  Não adotar uma estratégia de versionamento, o que força os consumidores de API a atualizarem e lançarem ou falharem com a evolução dos contratos de serviço. 
+  Mensagens de erro que vazam detalhes da implementação do serviço subjacente em vez de descreverem falhas de integração no contexto e no idioma do domínio. 
+  Não usar contratos de API para desenvolver casos de teste e simular implementações de API para permitir testes independentes dos componentes do serviço. 

 **Benefícios de estabelecer esta prática recomendada:** Sistemas distribuídos compostos por componentes que se comunicam por meio de contratos de serviço de API podem aumentar a confiabilidade. Os desenvolvedores podem detectar possíveis problemas no início do processo de desenvolvimento com a verificação de tipo durante a compilação a fim de verificar se as solicitações e as respostas seguem o contrato da API e se os campos obrigatórios estão presentes. Os contratos de API oferecem uma interface clara de autodocumentação de APIs e oferecem melhor interoperabilidade entre diferentes sistemas e linguagens de programação. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Depois de identificar os domínios de negócios e determinar a segmentação da workload, você pode desenvolver suas APIs de serviço. Primeiro, defina contratos de serviço legíveis por máquina para APIs e, depois, implemente uma estratégia de versionamento de API. Quando estiver pronto para integrar serviços em protocolos comuns, como REST, GraphQL ou eventos assíncronos, você poderá incorporar serviços da AWS à sua arquitetura para integrar seus componentes com contratos de API altamente tipificados. 

 **Serviços da AWS para contratos de API de serviços** 

 Incorpore serviços da AWS, incluindo [Amazon API Gateway](https://aws.amazon.com/api-gateway/), o [AWS AppSync](https://aws.amazon.com/appsync/)e o [Amazon EventBridge](https://aws.amazon.com/eventbridge/) à sua arquitetura para usar contratos de serviço de API em sua aplicação. O Amazon API Gateway ajuda você a se integrar diretamente a serviços nativos da AWS e outros serviços da web. O API Gateway é compatível com a [especificação da OpenAPI](https://github.com/OAI/OpenAPI-Specification) e versionamento. O AWS AppSync é um endpoint [GraphQL](https://graphql.org/) gerenciado que você configura definindo um esquema GraphQL para definir uma interface de serviço para consultas, mutações e assinaturas. O Amazon EventBridge usa esquemas de eventos para definir eventos e gerar associações de código para seus eventos. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Primeiro, defina um contrato para sua API. Um contrato expressará os recursos de uma API, bem como definirá objetos e campos de dados altamente tipificados para a entrada e a saída da API. 
+  Ao configurar APIs no API Gateway, você pode importar e exportar especificações da OpenAPI para seus endpoints. 
  +  [A importação de uma definição de OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) simplifica a criação de sua API e pode ser integrada a ferramentas de infraestrutura como código da AWS, como o [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) e o [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/). 
  +  [A exportação de uma definição de API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) simplifica a integração a ferramentas de teste de API e oferece ao consumidor de serviços uma especificação de integração. 
+  Você pode definir e gerenciar APIs do GraphQL com o AWS AppSync [definindo um arquivo de esquema GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) para gerar sua interface de contrato e simplificar a interação com modelos REST complexos, várias tabelas de banco de dados ou serviços legados. 
+  [Projetos do AWS Amplify](https://aws.amazon.com/amplify/) integrados ao AWS AppSync geram arquivos de consulta JavaScript altamente tipificados para uso em sua aplicação, bem como uma biblioteca cliente do AWS AppSync GraphQL para [tabelas do Amazon DynamoDB](https://aws.amazon.com/dynamodb/) . 
+  Quando você consome eventos de serviço do Amazon EventBridge, eles seguem os esquemas já existentes no registro do esquema ou os definidos com a especificação da OpenAPI. Com um esquema definido no registro, também é possível gerar vinculações de cliente a partir do contrato de esquema para integrar seu código aos eventos. 
+  Estender ou realizar o versionamento de sua API. Estender uma API é uma opção mais simples ao adicionar campos que podem ser configurados com campos opcionais ou valores padrão para campos obrigatórios. 
  +  Contratos baseados em JSON para protocolos, como REST e GraphQL, podem ser uma boa opção para a extensão do contrato. 
  +  Contratos baseados em XML para protocolos, como SOAP, devem ser testados com consumidores de serviços para determinar a viabilidade da extensão do contrato. 
+  Ao realizar o versionamento de uma API, considere implementar o controle de versão por procuração em que uma fachada é usada para oferecer compatibilidade com versões para que a lógica possa ser mantida em uma única base de código. 
  +  Com o API Gateway, você pode usar [mapeamentos de solicitações e respostas](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) para simplificar a absorção de alterações no contrato estabelecendo uma fachada para fornecer valores padrão para novos campos ou para retirar os campos removidos de uma solicitação ou resposta. Com essa abordagem, o serviço subjacente pode manter uma única base de código. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL03-BP02 Criar serviços enfocados em domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md) 
+  [REL04-BP02 Implementar dependências com acoplamento fraco](rel_prevent_interaction_failure_loosely_coupled_system.md) 
+  [REL05-BP03 Controlar e limitar as chamadas de repetição](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL05-BP05 Definir tempos limite do cliente](rel_mitigate_interaction_failure_client_timeouts.md) 

 **Documentos relacionados:** 
+ [ O que é uma API (interface de programação de aplicações)? ](https://aws.amazon.com/what-is/api/)
+ [ Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Compensações de microsserviços ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [ Microsserviços - uma definição desse novo termo de arquitetura ](https://www.martinfowler.com/articles/microservices.html)
+ [ Microsserviços na AWS](https://aws.amazon.com/microservices/)
+ [ Trabalhar com extensões do API Gateway para OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [ Especificação da OpenAPI ](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL: esquemas e tipos ](https:/graphql.org/learn/schema)
+ [ Vinculações de código do Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)

 **Exemplos relacionados:** 
+ [ Amazon API Gateway: configurar uma API REST usando o OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [ Amazon API Gateway para a aplicação CRUD Amazon DynamoDB usando OpenAPI ](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [ Padrões modernos de integração de aplicações em uma era sem servidor: integração do serviço API Gateway ](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [ Implementar o versionamento baseado em cabeçalho do API Gateway com Amazon CloudFront ](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: criar uma aplicação cliente ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)

 **Vídeos relacionados:** 
+ [ Usar a OpenAPI no AWS SAM para gerenciar o API Gateway ](https://www.youtube.com/watch?v=fet3bh0QA80)

 **Ferramentas relacionadas:** 
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)

# CONFIABILIDADE 4. Como projetar interações em um sistema distribuído para evitar falhas?
<a name="rel-04"></a>

Os sistemas distribuídos dependem das redes de comunicação para interconectar componentes, como servidores ou serviços. Sua carga de trabalho deve operar de forma confiável, apesar da perda de dados ou da latência nessas redes. Os componentes do sistema distribuído devem operar sem afetar negativamente outros componentes ou a carga de trabalho. Essas melhores práticas evitam falhas e melhoram o Mean Time Between Failures (MTBF – Tempo médio entre falhas).

**Topics**
+ [REL04-BP01 Identificar qual tipo de sistema distribuído é necessário](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementar dependências com acoplamento fraco](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Fazer um trabalho constante](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Fazer com que todas as respostas sejam idempotentes](rel_prevent_interaction_failure_idempotent.md)

# REL04-BP01 Identificar qual tipo de sistema distribuído é necessário
<a name="rel_prevent_interaction_failure_identify"></a>

 Os sistemas distribuídos em tempo real rígidos exigem respostas síncronas e rápidas, enquanto os sistemas em tempo real flexíveis têm uma janela de tempo para resposta maior, de minutos ou mais. Os sistemas off-line gerenciam as respostas por meio do processamento em lote ou assíncrono. Os sistemas distribuídos em tempo real rígidos têm os requisitos de confiabilidade mais rigorosos. 

 Os [desafios mais difíceis com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) são para sistemas complexos distribuídos em tempo real, também conhecidos como serviços de solicitação/resposta. O que as dificulta é que as solicitações chegam de forma imprevisível e as respostas devem ser fornecidas rapidamente (por exemplo, o cliente está aguardando ativamente a resposta). Os exemplos incluem servidores Web front-end, pipeline de pedidos, transações de cartão de crédito, todas as APIs da AWS e telefonia. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Identifique qual tipo de sistema distribuído é necessário. Os desafios dos sistemas distribuídos envolviam latência, escalabilidade, conhecimento das APIs de rede, marshalling e unmarshalling de dados e complexidade de algoritmos, como Paxos. À medida que os sistemas crescem e se tornam mais distribuídos, o que antes eram casos de borda hipotéticos se tornam ocorrências regulares. 
  +  [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
    +  Os sistemas distribuídos em tempo real rígidos exigem respostas síncronas e rápidas. 
    +  Os sistemas em tempo real flexíveis têm uma janela de tempo para resposta maior, de minutos ou mais. 
    +  Os sistemas off-line gerenciam as respostas por meio do processamento em lote ou assíncrono. 
    +  Os sistemas distribuídos em tempo real rígidos têm os requisitos de confiabilidade mais rigorosos. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+  [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [O que é o Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) 

 **Vídeos relacionados:** 
+  [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E) 

# REL04-BP02 Implementar dependências com acoplamento fraco
<a name="rel_prevent_interaction_failure_loosely_coupled_system"></a>

 As dependências, como sistemas de enfileiramento, sistemas de streaming, fluxos de trabalho e load balancers, têm acoplamento fraco. O baixo acoplamento ajuda a isolar o comportamento de um componente de outros componentes que dependem dele, aumentando a resiliência e a agilidade. 

 Em sistemas fortemente acoplados, as mudanças em um componente podem exigir mudanças em outros componentes que dependem dele, o que resulta em desempenho degradado em todos eles. O acoplamento fraco interrompe essa dependência de forma que os componentes dependentes só precisem conhecer a interface versionada e publicada. A implementação de um baixo acoplamento entre dependências isola uma falha em uma dependência para não afetar a outra. 

 O acoplamento fraco permite modificar o código ou adicionar recursos a um componente, minimizando o risco para outros componentes que dependem dele. Ele também permite resiliência detalhada em nível de componente, caso em que é possível aumentar a escala horizontalmente ou até mesmo alterar a implementação subjacente da dependência. 

 Para melhorar ainda mais a resiliência por meio do baixo acoplamento, torne as interações de componentes assíncronas sempre que possível. Esse modelo é adequado para qualquer interação que não precise de uma resposta imediata e em que uma confirmação de que uma solicitação foi registrada será suficiente. Envolve um componente que gera eventos e outro que os consome. Os dois componentes não se integram por meio de interação direta ponto a ponto, mas geralmente por meio de uma camada de armazenamento durável intermediária, como uma fila do Amazon SQS, uma plataforma de dados de streaming, como o AWS Step Functions, ou o Amazon Kinesis. 

![\[Diagram showing dependencies such as queuing systems and load balancers are loosely coupled\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/loosely-coupled-dependencies.png)


 Filas do Amazon SQS e Elastic Load Balancers são apenas duas maneiras de adicionar uma camada intermediária para baixo acoplamento. Arquiteturas orientadas a eventos também podem ser criadas na Nuvem AWS usando o Amazon EventBridge, que pode abstrair clientes (produtores de eventos) dos serviços dos quais eles dependem (consumidores de eventos). O Amazon Simple Notification Service (Amazon SNS) é uma solução eficaz quando você precisa de mensagens de alto throughput, baseadas em push e de muitos para muitos. Usando tópicos do Amazon SNS, seus sistemas de editores podem enviar mensagens para um grande número de endpoints assinantes para processamento paralelo. 

 Embora as filas ofereçam várias vantagens, na maioria dos sistemas complexos em tempo real, as solicitações mais antigas do que um tempo limite (geralmente segundos) devem ser consideradas obsoletas (o cliente desistiu e não está mais esperando por uma resposta) e não processadas. Dessa forma, as solicitações mais recentes (e provavelmente ainda válidas) podem ser processadas. 

 **Resultado desejado:** a implementação de dependências com acoplamento fraco permite minimizar a área de superfície da falha para o nível de componente, o que ajuda a diagnosticar e resolver problemas. Também simplifica os ciclos de desenvolvimento, permitindo que as equipes implementem mudanças em um nível modular sem impactar o desempenho de outros componentes que dependem delas. Essa abordagem fornece a capacidade de aumentar a escala horizontalmente em nível de componente com base nas necessidades dos recursos, bem como na utilização de um componente que contribui para a redução de custos. 

 **Antipadrões comuns:** 
+  Implantar uma workload monolítica. 
+  Invocar diretamente as APIs entre níveis de workload sem recurso de failover ou processamento assíncrono da solicitação. 
+  Acoplamento forte usando dados compartilhados. Sistemas com acoplamento fraco devem evitar o compartilhamento de dados por meio de bancos de dados compartilhados ou outras formas de armazenamento de dados fortemente acoplado, o que pode reintroduzir o acoplamento forte e impedir a escalabilidade. 
+  Ignorar a contrapressão. A workload deve ter a capacidade de diminuir ou interromper a entrada de dados quando um componente não puder processá-los na mesma velocidade. 

 **Benefícios do estabelecimento dessa prática recomendada:** o acoplamento fraco ajuda a isolar o comportamento de um componente de outros componentes que dependem dele, aumentando a resiliência e a agilidade. A falha em um componente é isolada dos demais. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Implemente dependências com acoplamento fraco. Existem várias soluções que permitem criar aplicações com acoplamento fraco. Isso inclui serviços para implementar filas totalmente gerenciadas, fluxos de trabalho automatizados, reação a eventos e APIs, entre outros, que podem ajudar a isolar o comportamento de componentes de outros componentes e, dessa forma, aumentar a resiliência e a agilidade. 
+  **Criar arquiteturas orientadas a eventos:** o [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) ajuda a criar arquiteturas orientadas a eventos com acoplamento fraco e distribuídas. 
+  **Implementar filas em sistemas distribuídos:** é possível usar o [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) para integrar e desacoplar sistemas distribuídos. 
+  **Conteinerizar componentes como microsserviços:** os [microsserviços](https://aws.amazon.com/microservices/) permitem que as equipes criem aplicações constituídas de pequenos componentes independentes que se comunicam por meio de APIs bem definidas. O [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) e o [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) podem ajudar você a começar a usar contêineres mais rapidamente. 
+  **Gerenciar fluxos de trabalho com o Step Functions:** o [Step Functions](https://aws.amazon.com/step-functions/getting-started/) ajuda você a coordenar vários serviços da AWS em fluxos de trabalho flexíveis. 
+  **Utilizar as arquiteturas de mensagens de publicação e assinatura (pub/sub):** o [ Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) fornece a entrega de mensagens dos publicadores aos assinantes (também conhecidos como produtores e consumidores). 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Os componentes em uma arquitetura orientada a eventos são iniciados por eventos. Eventos são ações que ocorrem em um sistema, como um usuário que adiciona um item a um carrinho. Quando uma ação é bem-sucedida, é gerado um evento que aciona o próximo componente do sistema. 
  + [ Building Event-driven Applications with Amazon EventBridge ](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
  + [AWS re:Invent 2022 - Designing Event-Driven Integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+  Os sistemas de mensagens distribuídos têm três partes principais que precisam ser implementadas para uma arquitetura baseada em fila. Eles incluem componentes do sistema distribuído, a fila usada para desacoplamento (distribuída em servidores do Amazon SQS) e as mensagens na fila. Um sistema típico tem produtores que iniciam a mensagem na fila e o consumidor que recebe a mensagem da fila. A fila armazena as mensagens em vários servidores do Amazon SQS para redundância. 
  + [ Basic Amazon SQS architecture ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
  + [ Send Messages Between Distributed Applications with Amazon Simple Queue Service ](https://aws.amazon.com/getting-started/hands-on/send-messages-distributed-applications/)
+  Os microsserviços, quando bem utilizados, melhoram a capacidade de manutenção e aumentam a escalabilidade, pois os componentes com acoplamento fraco são gerenciados por equipes independentes. Também permitem o isolamento de comportamentos em um único componente em caso de mudanças. 
  + [ Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
  + [ Let's Architect\$1 Architecting microservices with containers ](https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/)
+  Com o AWS Step Functions é possível criar aplicações distribuídas, automatizar processos, orquestrar microsserviços, entre outras coisas. A orquestração de vários componentes em um fluxo de trabalho automatizado permite desacoplar as dependências na aplicação. 
  + [ Create a Serverless Workflow with AWS Step Functions and AWS Lambda](https://aws.amazon.com/tutorials/create-a-serverless-workflow-step-functions-lambda/)
  + [ Conceitos básicos do AWS Step Functions](https://aws.amazon.com/step-functions/getting-started/)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon EC2: Ensuring Idempotency](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+  [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [O que é o Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) 
+ [ Break up with your monolith ](https://pages.awscloud.com/break-up-your-monolith.html)
+ [ Orchestrate Queue-based Microservices with AWS Step Functions and Amazon SQS ](https://aws.amazon.com/tutorials/orchestrate-microservices-with-message-queues-on-step-functions/)
+ [ Basic Amazon SQS architecture ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [Arquitetura baseada em fila](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/queue-based-architecture.html)

 **Vídeos relacionados:** 
+  [AWS New York Summit 2019: Introduction to event-driven architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E) 
+  [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q) 
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda ](https://www.youtube.com/watch?v=2rikdPIFc_Q)
+ [AWS re:Invent 2022 - Designing event-driven integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ [AWS re:Invent 2017: Elastic Load Balancing Deep Dive and Best Practices ](https://www.youtube.com/watch?v=9TwkMMogojY)

# REL04-BP03 Fazer um trabalho constante
<a name="rel_prevent_interaction_failure_constant_work"></a>

 Os sistemas podem falhar quando há alterações grandes e rápidas na carga. Por exemplo, se a sua workload está realizando uma verificação de integridade que monitora a integridade de milhares de servidores, ela deve sempre enviar a carga útil com o mesmo tamanho (um snapshot completo do estado atual). Se houver uma falha em todos os servidores ou se não houver falha alguma, o sistema de verificação de integridade realizará um trabalho constante sem alterações grandes e rápidas. 

 Por exemplo, se o sistema de verificação de integridade estiver monitorando 100.000 servidores, a carga nele será nominal a uma taxa de falha do servidor normalmente leve. No entanto, se um evento importante deixar metade desses servidores com problemas de integridade, o sistema de verificação de integridade ficará sobrecarregado tentando atualizar os sistemas de notificação e comunicar o estado com seus clientes. Portanto, em vez disso, o sistema de verificação de integridade deve enviar o snapshot completo do estado atual a cada vez. Os estados da integridade de 100.000 servidores, cada um representado por um bit, seriam apenas uma carga útil de 12,5 KB. independentemente de nenhum servidor ou falhar, ou todos eles falharem, o sistema de verificação de integridade está realizando um trabalho constante, e alterações grandes e rápidas não são uma ameaça para a estabilidade do sistema. Na verdade, é assim que o Amazon Route 53 lida com as verificações de integridade de endpoints (como endereços IP) para determinar como os usuários finais são roteados para eles. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Faça um trabalho constante para que os sistemas não falhem quando houver mudanças rápidas e grandes na carga. 
+  Implemente dependências com acoplamento fraco. As dependências, como sistemas de enfileiramento, sistemas de streaming, fluxos de trabalho e load balancers, têm acoplamento fraco. O baixo acoplamento ajuda a isolar o comportamento de um componente de outros componentes que dependem dele, aumentando a resiliência e a agilidade. 
  +  [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
  +  [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclui trabalho constante)](https://youtu.be/O8xLxNje30M?t=2482) 
    +  Para o exemplo de um sistema de verificação de integridade que monitora 100 mil servidores, crie as workloads de modo que os tamanhos da carga útil permaneçam constantes, seja qual for o número de êxitos ou falhas. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 

 **Vídeos relacionados:** 
+  [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclui trabalho constante)](https://youtu.be/O8xLxNje30M?t=2482) 
+  [AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E) 

# REL04-BP04 Fazer com que todas as respostas sejam idempotentes
<a name="rel_prevent_interaction_failure_idempotent"></a>

 Um serviço idempotente garante que cada solicitação seja concluída exatamente uma vez, de modo que fazer várias solicitações idênticas tem o mesmo efeito de uma única solicitação. Um serviço idempotente facilita para um cliente implementar novas tentativas sem o receio de que uma solicitação seja processada erroneamente várias vezes. Para fazer isso, os clientes podem emitir solicitações de API com um token de idempotência. O mesmo token é usado sempre que a solicitação é repetida. Uma API de serviço idempotente usa o token para retornar uma resposta idêntica à resposta que foi retornada na primeira vez que a solicitação foi concluída. 

 Em um sistema distribuído, é fácil executar uma ação no máximo uma vez (o cliente faz apenas uma solicitação) ou pelo menos uma vez (continue solicitando até o cliente receber a confirmação do sucesso). Porém, é difícil garantir que uma ação seja idempotente, o que significa que ela é executada *exatamente* uma vez, de modo que fazer várias solicitações idênticas tenha o mesmo efeito de uma única solicitação. Usando tokens de idempotência em APIs, os serviços podem receber uma solicitação mutante uma vez ou mais sem a criação de registros duplicados nem efeitos colaterais. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Faça com que todas as respostas sejam idempotentes. Um serviço idempotente garante que cada solicitação seja concluída exatamente uma vez, de modo que fazer várias solicitações idênticas tem o mesmo efeito de uma única solicitação. 
  +  Os clientes podem emitir solicitações de API com um token de idempotência. O mesmo token é usado sempre que a solicitação é repetida. Uma API de serviço idempotente usa o token para retornar uma resposta idêntica à resposta que foi retornada na primeira vez que a solicitação foi concluída. 
    +  [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 

 **Vídeos relacionados:** 
+  [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E) 

# CONFIABILIDADE 5. Como projetar interações em um sistema distribuído para mitigar ou resistir a falhas?
<a name="rel-05"></a>

Os sistemas distribuídos dependem de redes de comunicação para interconectar componentes (como servidores ou serviços). Sua carga de trabalho deve operar de forma confiável, apesar da perda de dados ou da latência nessas redes. Os componentes do sistema distribuído devem operar sem afetar negativamente outros componentes ou a workload. Essas práticas recomendadas permitem que as workloads resistam a tensões ou falhas, recuperem-se mais rapidamente delas e reduzam o impacto de tais prejuízos. Como resultado, o Mean Time To Recovery (MTTR – Tempo médio para recuperação) é melhorado.

**Topics**
+ [REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Controlar a utilização de solicitações](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controlar e limitar as chamadas de repetição](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Antecipar-se à falha e filas limitadas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Definir tempos limite do cliente](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Criar serviços sem estado sempre que possível](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementar medidas emergenciais](rel_mitigate_interaction_failure_emergency_levers.md)

# REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis
<a name="rel_mitigate_interaction_failure_graceful_degradation"></a>

Os componentes da aplicação devem continuar desempenhando sua função principal mesmo que as dependências se tornem indisponíveis. Eles podem estar fornecendo dados um pouco obsoletos, dados alternativos ou até mesmo nenhum dado. Isso garante que o funcionamento geral do sistema seja minimamente impedido por falhas localizadas e, ao mesmo tempo, ofereça o valor empresarial central.

 **Resultado desejado:** Quando as dependências de um componente não estão íntegras, o próprio componente ainda pode funcionar, embora de maneira prejudicada. Os modos de falha dos componentes devem ser vistos como operação normal. Os fluxos de trabalho devem ser projetados de forma que essas falhas não ocasionem à falha total ou, pelo menos, a estados previsíveis e recuperáveis. 

 **Antipadrões comuns:** 
+  Não identificar a principal funcionalidade empresarial necessária. Não testar se os componentes estão funcionando mesmo durante falhas de dependência. 
+  Não fornecer dados sobre erros ou quando apenas uma das várias dependências não está disponível e resultados parciais ainda podem ser retornados. 
+  Criar um estado inconsistente quando uma transação falha parcialmente. 
+  Não ter uma forma alternativa de acessar um armazenamento de parâmetros central. 
+  Invalidar ou esvaziar o estado local como resultado de uma falha na atualização sem levar em conta as consequências de fazer isso. 

 **Benefícios de estabelecer esta prática recomendada:** A degradação gradual melhora a disponibilidade do sistema como um todo e mantém as funções mais importantes em execução mesmo durante falhas. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A implementação de uma degradação gradual ajuda a minimizar o impacto das falhas de dependência na função do componente. Preferencialmente, um componente detecta falhas de dependência e as contorna de uma maneira que afete minimamente outros componentes ou clientes. 

 Arquitetar para uma degradação gradual significa considerar possíveis modos de falha durante o projeto de dependência. Para cada modo de falha, tenha uma maneira de fornecer a maior parte ou pelo menos a funcionalidade mais crítica do componente para chamadores ou clientes. Essas considerações podem se tornar requisitos adicionais que podem ser testados e verificados. Preferencialmente, um componente é capaz de realizar sua função principal de maneira aceitável, mesmo quando uma ou várias dependências falhem. 

 Trata-se tanto de uma discussão empresarial quanto técnica. Todos os requisitos empresariais são importantes e devem ser atendidos, se possível. No entanto, ainda faz sentido perguntar o que deve acontecer quando nem todos eles podem ser cumpridos. Um sistema pode ser projetado para estar disponível e ser consistente, mas em circunstâncias em que um requisito deve ser descartado, qual deles é mais importante? Para o processamento de pagamentos, pode ser a consistência. Para uma aplicação em tempo real, pode ser a disponibilidade. Para um site voltado para o cliente, a resposta pode depender das expectativas do cliente. 

 O que isso significa depende dos requisitos do componente e do que deve ser considerado sua função principal. Por exemplo: 
+  Um site de comércio eletrônico pode exibir dados de vários sistemas diferentes, como recomendações personalizadas, produtos mais bem classificados e status dos pedidos dos clientes na página de pouso. Quando um sistema upstream falha, ainda faz sentido exibir todo o resto em vez de mostrar uma página de erro para um cliente. 
+  Um componente que executa gravações em lote ainda poderá continuar processando um lote se ocorrer uma falha em uma das operações individuais. Deve ser simples implementar um mecanismo de repetição. Isso pode ser feito retornando informações sobre quais operações foram bem-sucedidas, quais falharam e por que falharam para o chamador, ou colocando solicitações com falha em uma fila de mensagens não entregues para implementar repetições assíncronas. As informações sobre operações com falha também devem ser registradas em log. 
+  Um sistema que processa transações deve verificar se todas ou nenhuma atualização individual foi executada. Para transações distribuídas, o padrão saga pode ser usado para reverter operações anteriores caso ocorra uma falha em uma operação posterior da mesma transação. Aqui, a função principal é manter a consistência. 
+  Sistemas essenciais devem ser capazes de lidar com dependências não correspondentes em tempo hábil. Nesses casos, o padrão do disjuntor pode ser usado. Quando as respostas de uma dependência começam a atingir o tempo limite, o sistema pode mudar para um estado fechado em que nenhuma chamada adicional é realizada. 
+  Uma aplicação pode ler parâmetros de um armazenamento de parâmetros. Pode ser útil criar imagens de contêiner com um conjunto padrão de parâmetros e usá-las caso o armazenamento de parâmetros não esteja disponível. 

 Observe que as vias percorridas em caso de falha do componente precisam ser testadas e devem ser significativamente mais simples do que a via principal. Geralmente, [estratégias alternativas devem ser evitadas](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/). 

## Etapas da implementação
<a name="implementation-steps"></a>

 Identifique dependências externas e internas. Leve em conta quais tipos de falhas podem ocorrer nelas. Pense em maneiras de minimizar o impacto negativo nos sistemas upstream e downstream e nos clientes durante essas falhas. 

 Veja a seguir uma lista de dependências e como degradar normalmente quando elas falham: 

1.  **Falha parcial das dependências:** Um componente pode fazer várias solicitações para sistemas downstream, como várias solicitações para um sistema ou uma solicitação para vários sistemas cada. Dependendo do contexto empresarial, diferentes maneiras de lidar com isso podem ser apropriadas (para obter mais detalhes, consulte exemplos anteriores em Orientações de implementação). 

1.  **Um sistema downstream não consegue processar solicitações devido à alta carga:** Se as solicitações para um sistema downstream falharem de modo consistente, não faz sentido continuar tentando. Isso pode criar carga adicional em um sistema já sobrecarregado e dificultar a recuperação. O padrão do disjuntor pode ser utilizado aqui, que monitora as chamadas com falha para um sistema downstream. Se ocorrer uma falha em um grande número de chamadas, ele deixará de enviar mais solicitações para o sistema downstream e só ocasionalmente permitirá que as chamadas passem para testar se o sistema downstream está disponível novamente. 

1.  **Um armazenamento de parâmetros não está disponível:** Para transformar um armazenamento de parâmetros, é possível usar o armazenamento em cache flexível de dependências ou padrões razoáveis incluídos nas imagens do contêiner ou da máquina. Observe que esses padrões precisam ser mantidos atualizados e incluídos nos pacotes de testes. 

1.  **Um serviço de monitoramento ou outra dependência não funcional não está disponível:** Se um componente não conseguir enviar logs, métricas ou rastreamentos de forma intermitente para um serviço de monitoramento central, geralmente é melhor continuar executando as funções empresariais normalmente. Não registrar em log nem enviar métricas silenciosamente por um longo período geralmente não é aceitável. Além disso, alguns casos de uso podem exigir entradas de auditoria completas para atender aos requisitos de conformidade. 

1.  **Uma instância primária de um banco de dados relacional pode não estar disponível:** Amazon Relational Database Service, como quase todos os bancos de dados relacionais, só pode ter uma instância primária de gravador. Isso cria um único ponto de falha para workloads de gravação e dificulta o ajuste de escala. Isso pode ser parcialmente reduzido com o uso de uma configuração Multi-AZ para alta disponibilidade ou da tecnologia sem servidor da Amazon Aurora para melhor ajuste de escala. Para requisitos de disponibilidade muito altos, pode fazer sentido não confiar no gravador principal. Para consultas que são somente leitura, podem ser usadas réplicas de leitura, que fornecem redundância e a capacidade de aumentar a escala horizontalmente, não apenas para verticalmente. As gravações podem ser armazenadas em buffer, por exemplo, em uma fila do Amazon Simple Queue Service, para que as solicitações de gravação dos clientes ainda possam ser aceitas mesmo que a primária esteja temporariamente indisponível. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon API Gateway: controlar a utilização das solicitações de API para um melhor throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+  [CircuitBreaker (resume “Circuit Breaker” do livro “Release It\$1”)](https://martinfowler.com/bliki/CircuitBreaker.html) 
+  [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [Michael Nygard “Release It\$1 Design and Deploy Production-Ready Software”](https://pragprog.com/titles/mnee2/release-it-second-edition/) 
+  [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) 
+  [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 
+  [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 
+  [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 

 **Vídeos relacionados:** 
+  [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328) (Repetição, recuo e jitter: AWS re:Invent 2019: Introdução à Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

 **Exemplos relacionados:** 
+  [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) 

# REL05-BP02 Controlar a utilização de solicitações
<a name="rel_mitigate_interaction_failure_throttle_requests"></a>

Controle a utilização das solicitações para reduzir o esgotamento de recursos devido a aumentos inesperados na demanda. Solicitações abaixo das taxas de controle de utilização são processadas, enquanto aquelas acima do limite definido são rejeitadas com uma mensagem de retorno indicando que o uso da solicitação foi controlado. 

 **Resultado desejado:** Grandes picos de volume, sejam causados por aumentos repentinos de tráfego de clientes, ataques de inundação ou tempestades de novas tentativas, são reduzidos pelo controle de utilização de solicitações, permitindo que as workloads continuem com o processamento normal do volume de solicitações compatível. 

 **Antipadrões comuns:** 
+  Os controles de utilização de endpoint da API não são implementados ou são mantidos em valores padrão sem considerar os volumes esperados. 
+  Não há teste de carregamento nem limites de controle de utilização dos endpoints da API. 
+  Controlar a utilização de taxas de solicitações sem considerar o tamanho ou a complexidade da solicitação. 
+  Testar as taxas máximas de solicitação ou o tamanho máximo da solicitação, mas não testar os dois juntos. 
+  Os recursos não são provisionados nos mesmos limites estabelecidos nos testes. 
+  Os planos de uso não foram configurados nem considerados para consumidores de API de aplicação para aplicação (A2A). 
+  Os consumidores da fila que escalam horizontalmente não têm as configurações máximas de simultaneidade configuradas. 
+  A limitação de taxas por endereço IP não foi implementada. 

 **Benefícios de estabelecer esta prática recomendada:** As workloads que definem limites de controle de utilização podem operar normalmente e processar a carga de solicitações aceitas com êxito em picos de volume inesperados. Os picos repentinos ou contínuos de solicitações para APIs e filas têm controle de utilização e não esgotam os recursos de processamento de solicitações. Os limites de taxas controlam a utilização de solicitantes individuais para que grandes volumes de tráfego de um único endereço IP ou consumidor de API não esgotem os recursos e afetem outros consumidores. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Os serviços devem ser projetados para processar uma capacidade conhecida de solicitações; essa capacidade pode ser estabelecida por meio de testes de carga. Se as taxas de chegada de solicitações excederem os limites, a resposta apropriada sinalizará que uma solicitação teve controle de utilização. Isso permite que o consumidor resolva o erro e tente novamente mais tarde. 

 Quando seu serviço exigir uma implementação de controle de utilização, considere implementar o algoritmo de bucket de token, em que um token é contabilizado para uma solicitação. Os tokens são recarregados a uma taxa de controle de utilização por segundo e esvaziados de forma assíncrona por meio de um token por solicitação. 

![\[Diagrama descrevendo o algoritmo do bucket de token.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/token-bucket-algorithm.png)


 

 [O Amazon API Gateway](https://aws.amazon.com/api-gateway/) implementa o algoritmo do bucket de token de acordo com os limites da conta e da região e pode ser configurado por cliente com planos de uso. Além disso, o [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) e o [Amazon Kinesis](https://aws.amazon.com/kinesis/) podem armazenar solicitações em buffer para suavizar a taxa de solicitações e permitir taxas de controle de utilização mais altas para solicitações que podem ser atendidas. Por fim, você pode implementar a limitação de taxa com o [AWS WAF](https://aws.amazon.com/waf/) para controlar a utilização de consumidores de API específicos que geram uma carga excepcionalmente alta. 

## Etapas da implementação
<a name="implementation-steps"></a>

 É possível configurar o API Gateway com limites de controle de utilização para suas APIs e retornar erros `“429 Muitas solicitações”` quando os limites são excedidos. Você pode usar o AWS WAF com seus endpoints do AWS AppSync e do API Gateway para habilitar o limite de taxa por endereço IP. Além disso, se seu sistema tolerar o processamento assíncrono, será possível colocar mensagens em uma fila ou em um fluxo para acelerar as respostas aos clientes do serviço, o que permite que você atinja taxas de controle de utilização mais altas. 

 Com o processamento assíncrono, ao configurar o Amazon SQS como fonte de eventos para o AWS Lambda, é possível [configurar a simultaneidade máxima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) para evitar que altas taxas de eventos consumam a cota de execução simultânea da conta disponível necessária para outros serviços em sua workload ou conta. 

 Embora o API Gateway ofereça uma implementação gerenciada do bucket de token, em casos em que não é possível usar o API Gateway, você pode utilizar as implementações de código aberto específicas da linguagem (veja exemplos relacionados em Recursos) do bucket de token para seus serviços. 
+  Entenda e configure [limites de controle de utilização do API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) em nível de conta por região, API por estágio e chave de API por nível do plano de uso. 
+  Aplique [regras de controle de utilização de taxas do AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) para endpoints do API Gateway e do AWS AppSync a fim de se proteger contra inundações e bloquear IPs mal-intencionados. As regras de controle de utilização de taxas também podem ser configuradas em chaves de API do AWS AppSync para consumidores A2A. 
+  Decida se você precisa de mais controle de limitação do que limitação de taxas para APIs do AWS AppSync e, em caso afirmativo, configure um API Gateway na frente do seu endpoint do AWS AppSync. 
+  Quando filas do Amazon SQS são configuradas como gatilhos para os consumidores da fila do Lambda, defina a [simultaneidade máxima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) como um valor que processe o suficiente para atender aos seus objetivos de nível de serviço, mas não consuma limites de simultaneidade que afetem outras funções do Lambda. Considere definir a simultaneidade reservada em outras funções do Lambda na mesma conta e região ao consumir filas com o Lambda. 
+  Use o API Gateway com integrações de serviços nativos para Amazon SQS ou Kinesis para armazenar solicitações em buffer. 
+  Se você não puder usar o API Gateway, consulte bibliotecas específicas de linguagens para implementar o algoritmo do bucket de token para sua workload. Confira a seção de exemplos e faça sua própria pesquisa para encontrar uma biblioteca adequada. 
+  Teste os limites que você planeja definir ou permitir que sejam aumentados e documente os limites testados. 
+  Não aumente os limites além do que você estabeleceu nos testes. Ao aumentar um limite, verifique se os recursos provisionados já são equivalentes ou maiores do que os dos cenários de teste antes de aplicar o aumento. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL04-BP03 Fazer um trabalho constante](rel_prevent_interaction_failure_constant_work.md) 
+  [REL05-BP03 Controlar e limitar as chamadas de repetição](rel_mitigate_interaction_failure_limit_retries.md) 

 **Documentos relacionados:** 
+  [Amazon API Gateway: controlar a utilização das solicitações de API para um melhor throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+ [AWS WAF: instrução de regra baseada em taxas ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Introdução da máxima simultaneidade do AWS Lambda ao usar o Amazon SQS como fonte de eventos ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda: simultaneidade máxima ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)

 **Exemplos relacionados:** 
+ [ As três regras mais importantes baseadas em taxas do AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Java Bucket4j ](https://github.com/bucket4j/bucket4j)
+ [ Bucket de tokens do Python ](https://pypi.org/project/token-bucket/)
+ [ Bucket de tokens do Node ](https://www.npmjs.com/package/tokenbucket)
+ [ Limitação da taxa de segmentação do sistema .NET ](https://www.nuget.org/packages/System.Threading.RateLimiting)

 **Vídeos relacionados:** 
+ [ Implementing GraphQL API security best practices with AWS AppSync (Implementação das práticas recomendadas de segurança da API GraphQL com AWS AppSync) ](https://www.youtube.com/watch?v=1ASMLeJ_15U)

 **Ferramentas relacionadas:** 
+ [ O Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)

# REL05-BP03 Controlar e limitar as chamadas de repetição
<a name="rel_mitigate_interaction_failure_limit_retries"></a>

Use o recuo exponencial para repetir as solicitações em intervalos progressivamente maiores entre cada nova repetição. Introduza o jitter entre as repetições para tornar os intervalos de repetição aleatórios. Limite o número máximo de repetições.

 **Resultado desejado:** Os componentes típicos em um sistema de software distribuído incluem servidores, load balancers, bancos de dados e servidores DNS. Durante a operação normal, esses componentes podem responder a solicitações com erros temporários ou limitados, além de erros que seriam persistentes, independentemente de repetições. Quando os clientes fazem solicitações aos serviços, elas consomem recursos, incluindo memória, threads, conexões, portas ou quaisquer outros recursos limitados. Controlar e limitar as repetições é uma estratégia para liberar e minimizar o consumo de recursos para que os componentes do sistema sob pressão não fiquem sobrecarregados. 

 Quando as solicitações do cliente atingem o tempo limite ou recebem respostas de erro, ele deve determinar se deve ou não tentar novamente. Se tentar novamente, ele o fará com um recuo exponencial com jitter e um valor máximo de repetição. Como resultado, os serviços e os processos de back-end recebem alívio da carga e do tempo de recuperação automática, ocasionando uma recuperação mais rápida e atendimento bem-sucedido das solicitações. 

 **Antipadrões comuns:** 
+  Implementar repetições sem adicionar recuo exponencial, jitter e valores máximos de repetição. O recuo e o jitter ajudam a evitar picos artificiais de tráfego devido a repetições coordenadas involuntariamente em intervalos comuns. 
+  Implementar repetições sem testar seus efeitos ou presumir que repetições já estejam incorporadas a um SDK sem testar cenários de repetição. 
+  Não entender os códigos de erro publicados das dependências, ocasionando a repetição de todos os erros, inclusive aqueles com uma causa clara que indica falta de permissão, erro de configuração ou outra condição que, previsivelmente, não será resolvida sem intervenção manual. 
+  Não abordar práticas de observabilidade, incluindo monitoramento e alertas sobre falhas repetidas de serviço para que os problemas subjacentes sejam divulgados e possam ser resolvidos. 
+  Desenvolver mecanismos de repetição personalizados quando os recursos de repetição integrados ou de terceiros são suficientes. 
+  Tentar novamente em várias camadas da pilha de aplicações de uma forma que agrava as tentativas de repetição, consumindo ainda mais recursos em uma tempestade de repetições. Entenda como esses erros afetam sua aplicação, as dependências nas quais você confia e implemente repetições em apenas um nível. 
+  Repetir chamadas de serviço que não são idempotentes, causando efeitos colaterais inesperados, como resultados duplicados. 

 **Benefícios de estabelecer esta prática recomendada:** As repetições ajudam os clientes a obter os resultados desejados quando as solicitações falham, mas também consomem mais tempo do servidor para obter as respostas bem-sucedidas que eles desejam. Quando as falhas são raras ou transitórias, as repetições funcionam bem. Quando as falhas são causadas pela sobrecarga de recursos, as repetições podem piorar as coisas. Adicionar um recuo exponencial com jitter às repetições do cliente permite que os servidores se recuperem quando as falhas são causadas pela sobrecarga de recursos. O jitter evita o alinhamento das solicitações em picos, e o recuo diminui o escalonamento de carga causado pela adição de repetições à carga normal da solicitação. Por fim, é importante configurar um número máximo de repetições ou o tempo decorrido para evitar a criação de backlogs que produzam falhas metaestáveis. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Controle e limite as chamadas de repetição. Use o recuo exponencial para tentar novamente após intervalos progressivamente mais longos. Introduza jitter para tornar esses intervalos de repetição aleatórios e limite o número máximo de repetições. 

 Alguns AWS SDKs implementam repetições e recuo exponencial por padrão. Use essas implementações integradas da AWS quando aplicável em sua workload. Implemente uma lógica semelhante em sua workload ao chamar serviços que sejam idempotentes e em que repetições melhorem a disponibilidade do cliente. Decida quais são os tempos limite e quando parar de tentar novamente com base no seu caso de uso. Crie e exercite cenários de teste para esses casos de uso de repetições. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Determine a camada ideal em sua pilha de aplicações para implementar repetições para os serviços dos quais sua aplicação depende. 
+  Conheça os SDKs existentes que implementam estratégias comprovadas de repetição com retrocesso exponencial e jitter para a linguagem de sua escolha e dê preferência a esses SDKs em vez de escrever suas próprias implementações de repetição. 
+  Verifique se [os serviços são idempotentes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) antes de implementar repetições. Depois que as repetições forem implementadas, elas devem ser testadas e exercitadas regularmente na produção. 
+  Ao chamar APIs de serviço da AWS, use os [AWS SDKs](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) e o [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html) e entenda as opções de configuração de repetições. Determine se os padrões funcionam para seu caso de uso, teste e ajuste conforme necessário. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL04-BP04 Fazer com que todas as respostas sejam idempotentes](rel_prevent_interaction_failure_idempotent.md) 
+  [REL05-BP02 Controlar a utilização de solicitações](rel_mitigate_interaction_failure_throttle_requests.md) 
+  [REL05-BP04 Antecipar-se à falha e filas limitadas](rel_mitigate_interaction_failure_fail_fast.md) 
+  [REL05-BP05 Definir tempos limite do cliente](rel_mitigate_interaction_failure_client_timeouts.md) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md) 

 **Documentos relacionados:** 
+  [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 
+ [ Recuo exponencial e jitter ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [ Tornar as tentativas seguras com APIs idempotentes ](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

 **Exemplos relacionados:** 
+ [ Repetição Spring ](https://github.com/spring-projects/spring-retry)
+ [ Repetição Resilience4j ](https://resilience4j.readme.io/docs/retry)

 **Vídeos relacionados:** 
+  [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328) (Repetição, recuo e jitter: AWS re:Invent 2019: Introdução à biblioteca de criadores da Amazon (DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

 **Ferramentas relacionadas:** 
+ [AWS SDKs e ferramentas: comportamento de repetição ](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: repetições da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)

# REL05-BP04 Antecipar-se à falha e filas limitadas
<a name="rel_mitigate_interaction_failure_fail_fast"></a>

Quando um serviço não consegue responder com êxito a uma solicitação, antecipe-se à falha. Isso permite a liberação dos recursos associados a uma solicitação e possibilita que o serviço se recupere se estiver ficando sem recursos. Antecipar-se à falha é um padrão de design de software bem estabelecido que pode ser utilizado para criar workloads altamente confiáveis na nuvem. As filas também correspondem a um padrão de integração empresarial bem estabelecido que pode facilitar o carregamento e permitir que os clientes liberem recursos quando o processamento assíncrono pode ser tolerado. Quando um serviço consegue responder com êxito em condições normais, mas falha quando a taxa de solicitações é muito alta, use uma fila para armazenar solicitações em buffer. No entanto, não permita a formação de backlogs de filas longas que possam ocasionar o processamento de solicitações antigas das quais um cliente já desistiu.

 **Resultado desejado:** Quando os sistemas enfrentam contenção de recursos, tempos limite, exceções ou falhas de causa desconhecida que tornam os objetivos de nível de serviço inatingíveis, as estratégias de antecipação a falhas permitem uma recuperação mais rápida do sistema. Sistemas que precisam absorver picos de tráfego e acomodar o processamento assíncrono podem melhorar a confiabilidade ao permitir que os clientes liberem solicitações rapidamente usando filas para armazenar solicitações em buffer para serviços de back-end. Ao armazenar solicitações em filas, estratégias de gerenciamento de filas são implementadas para evitar backlogs intransponíveis. 

 **Antipadrões comuns:** 
+  Implementar filas de mensagens, mas não configurar filas de mensagens não entregues (DLQ) ou alarmes em volumes DLQ para detectar quando um sistema está em falha. 
+  Não medir a idade das mensagens em uma fila, uma medida de latência para entender quando os consumidores da fila estão ficando para trás ou cometendo erros, ocasionando repetições. 
+  Não limpar mensagens pendentes de uma fila, quando não há utilidade em processar essas mensagens se a necessidade empresarial deixar de existir. 
+  Configurar filas do tipo “first in first out” (FIFO) quando filas do tipo “last in first out” (LIFO) atenderia melhor às necessidades do cliente, por exemplo, quando a ordenação rigorosa não é necessária e o processamento de backlog está atrasando todas as solicitações novas e urgentes, ocasionando violação dos níveis de serviço de todos os clientes. 
+  Expor filas internas aos clientes em vez de expor APIs que gerenciem a entrada de trabalho e coloquem as solicitações em filas internas. 
+  Combinar muitos tipos de solicitações de trabalho em uma única fila, o que pode agravar as condições de backlog ao distribuir a demanda de recursos entre os tipos de solicitação. 
+  Processar solicitações complexas e simples na mesma fila, apesar da necessidade de monitoramento, tempos limite e alocação de recursos diferentes. 
+  Não validar entradas ou usar afirmações para implementar mecanismos de antecipação à falha em software que agreguem exceções a componentes de nível superior que podem lidar com erros sem problemas. 
+  Não remover recursos com defeito do roteamento de solicitações, principalmente quando as falhas estão emitindo êxitos e falhas em decorrência de travamento e reinicialização, falha de dependência intermitente, capacidade reduzida ou perda de pacotes de rede. 

 **Benefícios de estabelecer esta prática recomendada:** Sistemas que se antecipam à falha são mais fáceis de depurar e corrigir e geralmente expõem problemas de codificação e configuração antes que as versões sejam publicadas em produção. Os sistemas que incorporam estratégias eficazes de filas oferecem maior resiliência e confiabilidade a picos de tráfego e às condições intermitentes de falha do sistema. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 As estratégias de antecipação à falha podem ser codificadas em soluções de software e configuradas em infraestrutura. Além de se anteciparem à falha, as filas são uma técnica arquitetônica simples, mas poderosa, para dissociar os componentes do sistema e facilitar o carregamento. [O Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) oferece recursos para monitorar e alertar sobre falhas. Quando se sabe que um sistema está falhando, estratégias de mitigação podem ser invocadas, inclusive evitar recursos afetados. Quando os sistemas implementam filas com o [Amazon SQS](https://aws.amazon.com/sqs/) e outras tecnologias de fila para facilitar o carregamento, eles devem considerar como gerenciar os backlogs de filas, bem como as falhas no consumo de mensagens. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Implemente afirmações programáticas ou métricas específicas em seu software e use-as para alertar explicitamente sobre problemas do sistema. O Amazon CloudWatch ajuda você a criar métricas e alarmes com base no padrão de log da aplicação e na instrumentação do SDK. 
+  Use métricas e alarmes do CloudWatch para eliminar recursos danificados que estão aumentando a latência no processamento ou falhando repetidamente no processamento das solicitações. 
+  Use o processamento assíncrono criando APIs para aceitar e anexar solicitações às filas internas usando o Amazon SQS e, depois, responder ao cliente que produz a mensagem com uma mensagem de êxito para que o cliente possa liberar recursos e prosseguir com outros trabalhos enquanto os consumidores da fila de back-end processam as solicitações. 
+  Avalie e monitore a latência do processamento da fila produzindo uma métrica do CloudWatch sempre que retirar uma mensagem de uma fila, comparando o momento presente com o carimbo de data/hora da mensagem. 
+  Quando falhas impedem o processamento bem-sucedido de mensagens ou geram picos de tráfego em volumes que não podem ser processados de acordo com acordos de serviço, deixe de lado o tráfego antigo ou excedente para uma fila de transbordamento. Isso permite o processamento prioritário de trabalhos novos e antigos, quando há capacidade disponível. Essa técnica é uma aproximação do processamento LIFO e permite o processamento normal do sistema para todos os novos trabalhos. 
+  Use filas de mensagens não entregues ou de redirecionamento para mover mensagens que não podem ser processadas do backlog para um local que possa ser pesquisado e resolvido posteriormente. 
+  Tente novamente ou, quando possível, elimine as mensagens antigas comparando o momento presente com o carimbo de data/hora da mensagem e descartando as mensagens que não são mais relevantes para o cliente solicitante. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL04-BP02 Implementar dependências com acoplamento fraco](rel_prevent_interaction_failure_loosely_coupled_system.md) 
+  [REL05-BP02 Controlar a utilização de solicitações](rel_mitigate_interaction_failure_throttle_requests.md) 
+  [REL05-BP03 Controlar e limitar as chamadas de repetição](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL06-BP02 Definir e calcular as métricas (agregação)](rel_monitor_aws_resources_notification_aggregation.md) 
+  [REL06-BP07 Monitorar o rastreamento completo das solicitações por meio de seu sistema](rel_monitor_aws_resources_end_to_end.md) 

 **Documentos relacionados:** 
+ [ Evitar backlogs de fila intransponíveis ](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+  [Falha rápida](https://www.martinfowler.com/ieeeSoftware/failFast.pdf) 
+ [ Como evitar um aumento do backlog de mensagens na minha fila do Amazon SQS? ](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [ Elastic Load Balancing: mudança de zona ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [ Controlador de recuperação de aplicações Amazon Route 53: controle de roteamento para failover de tráfego ](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)

 **Exemplos relacionados:** 
+ [ Padrões de integração empresarial: canal de mensagens não entregues ](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)

 **Vídeos relacionados:** 
+  [AWS re:Invent 2022 - Operating highly available Multi-AZ applications (re:Invent 2022: operar aplicações Multi-AZ altamente disponíveis)](https://www.youtube.com/watch?v=mwUV5skJJ0s) 

 **Ferramentas relacionadas:** 
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon MQ ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [ O Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)

# REL05-BP05 Definir tempos limite do cliente
<a name="rel_mitigate_interaction_failure_client_timeouts"></a>

Defina tempos limite adequados para conexões e solicitações, verifique-os sistematicamente e não confie nos valores padrão, pois eles não estão cientes das especificações da workload.

 **Resultado desejado:** Os tempos limite do cliente devem considerar o custo para o cliente, o servidor e a workload associados à espera por solicitações que levam um tempo anormal para serem concluídas. Como não é possível saber a causa exata de nenhum tempo limite, os clientes devem usar o conhecimento dos serviços para desenvolver expectativas de causas prováveis e prazos apropriados. 

 As conexões do cliente atingem o tempo limite com base nos valores configurados. Depois de encontrar um tempo limite, os clientes tomam a decisão de recuar e tentar novamente ou abrir um [disjuntor](https://martinfowler.com/bliki/CircuitBreaker.html). Esses padrões evitam a emissão de solicitações que podem exacerbar uma condição de erro subjacente. 

 **Antipadrões comuns:** 
+  Não estar ciente dos tempos limite do sistema ou dos tempos limite padrão. 
+  Não estar ciente do tempo normal de conclusão da solicitação. 
+  Não estar ciente das possíveis causas das solicitações levarem muito tempo para serem concluídas ou dos custos de performance do cliente, do serviço ou da workload associados à espera por essas conclusões. 
+  Não estar ciente da probabilidade de uma rede danificada fazer com que uma solicitação falhe somente quando o tempo limite é atingido e dos custos para a performance do cliente e da workload por não adotar um tempo limite mais curto. 
+  Não testar cenários de tempo limite tanto para conexões quanto para solicitações. 
+  Definir tempos limite muito altos, o que pode resultar em longos tempos de espera e aumentar a utilização de recursos. 
+  Definir tempos limite muito baixos, gerando falhas artificiais. 
+  Ignorar padrões para lidar com erros de tempo limite para chamadas remotas, como disjuntores e novas tentativas. 
+  Não considerar o monitoramento de taxas de erro de chamadas de serviço, objetivos de nível de serviço para latência e valores atípicos de latência. Essas métricas podem fornecer informações sobre tempos limite agressivos ou permissivos. 

 **Benefícios de estabelecer esta prática recomendada:** Os tempos limite de chamadas remotas são configurados e os sistemas são projetados para lidar com os tempos limite normalmente, de forma que os recursos sejam conservados quando as chamadas remotas respondem de forma anormalmente lenta e os erros de tempo limite são tratados normalmente pelos clientes do serviço. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Defina um tempo limite de conexão e um tempo limite de solicitação em qualquer chamada de dependência de serviço e, geralmente, em qualquer chamada entre processos. Muitas frameworks oferecem recursos de tempo limite integrados, mas tenha cuidado, pois algumas têm valores padrão infinitos ou superiores ao aceitável para seus objetivos de serviço. Um valor muito alto reduz a utilidade do tempo limite porque os recursos continuam a ser consumidos enquanto o cliente aguarda o decorrer do tempo limite. Um valor muito baixo pode gerar maior tráfego no back-end e maior latência, porque muitas solicitações são repetidas. Em alguns casos, isso pode levar a interrupções completas porque todas as solicitações estão sendo repetidas. 

 Considere o seguinte ao determinar as estratégias de tempo limite: 
+  As solicitações podem levar mais tempo do que o normal para serem processadas devido ao conteúdo, a deficiências em um serviço de destino ou a uma falha na partição de rede. 
+  Solicitações com conteúdo anormalmente caro podem consumir recursos desnecessários do servidor e do cliente. Nesse caso, reduzir o tempo limite dessas solicitações e não tentar novamente pode preservar os recursos. Os serviços também devem se proteger de conteúdo anormalmente caro com limitações e tempos limite do servidor. 
+  Solicitações que demoram muito devido a uma falha no serviço podem expirar e ser repetidas. Deve-se considerar os custos do serviço para a solicitação e a nova tentativa, mas se a causa for uma deficiência localizada, uma nova tentativa provavelmente não será cara e reduzirá o consumo de recursos do cliente. O tempo limite também pode liberar recursos do servidor, dependendo da natureza da deficiência. 
+  Solicitações que demoram muito para serem concluídas porque a solicitação ou a resposta não foi entregue pela rede podem expirar e ser repetidas. Como a solicitação ou a resposta não foi entregue, a falha teria sido o resultado, independentemente da duração do tempo limite. Nesse caso, o tempo limite não liberará recursos do servidor, mas liberará recursos do cliente e melhorará a performance da workload. 

 Aproveite os padrões de design bem estabelecidos, como novas tentativas e disjuntores, para lidar com os tempos de espera de forma eficiente e oferecer compatibilidade com abordagens de antecipação à falha. [AWS SDKs](https://docs.aws.amazon.com/index.html#sdks) e a [AWS CLI](https://aws.amazon.com/cli/) permitem a configuração dos tempos limite de conexão e solicitação e as repetições com recuo exponencial e instabilidade. [As funções do AWS Lambda](https://aws.amazon.com/lambda/) são compatíveis com a configuração de tempos limite e com o [AWS Step Functions](https://aws.amazon.com/step-functions/), você pode criar disjuntores de uso de pouco código que utilizam integrações pré-incorporadas com serviços da AWS e SDKs. [O AWS App Mesh](https://aws.amazon.com/app-mesh/) Envoy oferece recursos de tempo limite e disjuntor. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Configure tempos limite em chamadas de serviço remoto e utilize os recursos de tempo limite de linguagem integrados ou as bibliotecas de tempo limite de código aberto. 
+  Quando sua workload fizer chamadas com um AWS SDK, revise a documentação para saber a configuração de tempo limite específica da linguagem. 
  + [ Python ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
  + [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
  + [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
  + [ Ruby ](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
  + [ Java ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
  + [ Go ](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
  + [ Node.js ](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
  + [ C\$1\$1 ](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+  Ao usar AWS SDKs ou comandos da AWS CLI em sua workload, configure os valores de tempo limite padrão definindo [os padrões de configuração da AWS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) de `connectTimeoutInMillis` e `tlsNegotiationTimeoutInMillis`. 
+  Aplique [opções de linha de comando](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout` e `cli-read-timeout` para controlar comandos únicos da AWS CLI para serviços da AWS. 
+  Monitore o tempo limite de chamadas de serviço remoto e defina alarmes para erros persistentes para que você possa lidar proativamente com cenários de erro. 
+  Implemente [métricas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) e [detecção de anomalias do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) em taxas de erro de chamada, objetivos de nível de serviço para latência e valores atípicos de latência para fornecer informações sobre o gerenciamento de tempos limite excessivamente agressivos ou permissivos. 
+  Configure tempos limite em [funções do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console). 
+  Os clientes do API Gateway devem implementar suas próprias repetições ao lidar com os tempos limite. O API Gateway é compatível com um [tempo limite de integração de 50 milissegundos a 29 segundos](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) para integrações posteriores e não tenta novamente quando as solicitações de integração atingem o tempo limite. 
+  Implemente o padrão de [disjuntor](https://martinfowler.com/bliki/CircuitBreaker.html) para evitar fazer chamadas remotas quando o tempo limite está prestes a ser atingido. Abra o circuito para evitar falhas nas chamadas e feche-o quando as chamadas estiverem respondendo normalmente. 
+  Para workloads baseadas em contêineres, analise os recursos do [App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) para utilizar os tempos limite e os disjuntores integrados. 
+  Use o AWS Step Functions para criar disjuntores de pouco uso de código para chamadas de serviço remoto, especialmente ao chamar AWS SDKs nativos e integrações do Step Functions compatíveis para simplificar sua workload. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL05-BP03 Controlar e limitar as chamadas de repetição](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL05-BP04 Antecipar-se à falha e filas limitadas](rel_mitigate_interaction_failure_fail_fast.md) 
+  [REL06-BP07 Monitorar o rastreamento completo das solicitações por meio de seu sistema](rel_monitor_aws_resources_end_to_end.md) 

 **Documentos relacionados:** 
+  [AWS SDK: repetições e tempos limite](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) 
+  [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 
+ [ Cotas do Amazon API Gateway e notas importantes ](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface: opções de linha de comando ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: configurar tempos limite de API ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS Botocore usando o objeto de configuração e a referência de configuração ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK para .NET: repetições e tempos limite ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda: configurar as opções de função do Lambda ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)

 **Exemplos relacionados:** 
+ [ Usar o padrão do disjuntor com o AWS Step Functions e o Amazon DynamoDB ](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [ Martin Fowler: CircuitBreaker ](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)

 **Ferramentas relacionadas:** 
+ [AWS SDKs ](https://docs.aws.amazon.com/index.html#sdks)
+ [ As funções do AWS Lambda](https://aws.amazon.com/lambda/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)

# REL05-BP06 Criar serviços sem estado sempre que possível
<a name="rel_mitigate_interaction_failure_stateless"></a>

 Os serviços não devem exigir estado ou devem descarregar o estado de modo que não haja dependência entre solicitações de clientes diferentes em relação aos dados armazenados localmente no disco ou na memória. Isso permite que os servidores sejam substituídos quando necessário sem causar impacto na disponibilidade. O Amazon ElastiCache ou o Amazon DynamoDB são bons destinos para o estado descarregado. 

![\[Nesta aplicação Web sem estado, o estado da sessão é descarregado para o Amazon ElastiCache.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/stateless-webapp.png)


 Quando os usuários ou serviços interagem com um aplicativo, eles geralmente executam uma série de interações que formam uma sessão. Uma sessão são dados exclusivos para usuários que persistem entre solicitações enquanto usam o aplicativo. Um aplicativo sem estado é um aplicativo que não precisa de conhecimento de interações anteriores e não armazena informações da sessão. 

 Depois de projetados para serem sem estado, você pode usar serviços de computação com tecnologia sem servidor, como o AWS Lambda ou o AWS Fargate. 

 Além da substituição do servidor, outro benefício dos aplicativos sem estado é que eles podem escalar horizontalmente, pois qualquer um dos recursos de computação disponíveis (como instâncias do EC2 e funções do AWS Lambda) pode atender a qualquer solicitação. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Crie aplicações sem estado. Os aplicativos sem estado permitem a escalabilidade horizontal e são tolerantes a falhas de um nó individual. 
  +  Remova o estado que realmente pode ser armazenado nos parâmetros de solicitação. 
  +  Depois de examinar se o estado é necessário, mova qualquer rastreamento de estado para um armazenamento em cache resiliente multizona ou armazenamento de dados, como o Amazon ElastiCache, o Amazon RDS, Amazon DynamoDB ou uma solução de dados distribuídos de terceiros. Armazene os estados que não puderam ser movidos para armazenamentos de dados resilientes. 
    +  Alguns dados (como cookies) podem ser inseridos em cabeçalhos ou parâmetros de consulta. 
    +  Faça a refatoração para remover o estado que pode ser inserido rapidamente nas solicitações. 
    +  Alguns dados talvez não sejam realmente necessários por solicitação e podem ser recuperados sob demanda. 
    +  Remova os dados que podem ser recuperados de forma assíncrona. 
    +  Escolha um armazenamento de dados que atenda aos requisitos de um estado necessário. 
    +  Considere um banco de dados NoSQL para dados não relacionais. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) 
+  [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 
+  [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 

# REL05-BP07 Implementar medidas emergenciais
<a name="rel_mitigate_interaction_failure_emergency_levers"></a>

 Medidas emergenciais são processos rápidos que podem atenuar o impacto da disponibilidade na workload. 

 As medidas emergenciais funcionam com a desativação, o controle de utilização ou a alteração do comportamento dos componentes ou das dependências com o uso de mecanismos conhecidos e testados. Isso pode aliviar as deficiências da workload decorrentes da exaustão dos recursos provocada por aumentos inesperados na demanda e reduzir o impacto de falhas em componentes não essenciais da workload. 

 **Resultado desejado:** ao implementar medidas de emergência, é possível estabelecer processos bem conhecidos para manter a disponibilidade dos componentes essenciais na workload. A workload deve se degradar normalmente e continuar desempenhando suas funções essenciais aos negócios durante a ativação de uma medida emergencial. Para obter mais detalhes sobre a degradação simples, consulte [REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html). 

 **Antipadrões comuns:** 
+  A falha de dependências não essenciais afeta a disponibilidade da workload principal. 
+  Não testar ou verificar o comportamento dos componentes essenciais durante a deterioração de componentes não essenciais. 
+  Não há critérios claros e determinísticos definidos para ativação ou desativação de uma medida emergencial. 

 **Benefícios do estabelecimento desta prática recomendada:** a implementação de medidas emergenciais pode melhorar a disponibilidade dos componentes essenciais na workload fornecendo aos resolvedores processos estabelecidos para responder a picos inesperados na demanda ou a falhas de dependências não essenciais. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Identifique os componentes essenciais na workload. 
+  Projete e arquitete os componentes essenciais na workload para resistirem à falha de componentes não essenciais. 
+  Conduza testes para validar o comportamento dos componentes essenciais durante a falha de componentes não essenciais. 
+  Defina e monitore métricas ou acionadores relevantes para iniciar procedimentos de medida emergencial. 
+  Defina os procedimentos (manuais ou automatizados) que compõem a medida emergencial. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Identificar os componentes essenciais aos negócios na workload. 
  +  Cada componente técnico na workload deve ser mapeado para a função de negócios relevante e classificado como essencial ou não essencial. Para obter exemplos de funcionalidades essenciais e não essenciais na Amazon, consulte [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering). 
  +  Essa é uma decisão técnica e de negócios e varia de acordo com a organização e a workload. 
+  Projete e arquitete os componentes essenciais na workload para resistirem à falha de componentes não essenciais. 
  +  Durante a análise de dependências, considere todos os possíveis modos de falha e verifique se os mecanismos de medida emergencial fornecem a funcionalidade essencial aos componentes subsequentes. 
+  Conduza testes para validar o comportamento dos componentes essenciais durante a ativação das medidas emergenciais. 
  +  Evite o comportamento bimodal. Para obter mais detalhes, consulte [ REL11-BP05 Usar estabilidade estática para evitar o comportamento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html). 
+  Defina, monitore e emita alertas sobre as métricas relevantes para iniciar o procedimento de medida emergencial. 
  +  A descoberta das métricas certas a serem monitoradas depende da workload. Alguns exemplos de métricas são a latência ou o número de solicitações com falha feitas para uma dependência. 
+  Defina os procedimentos, manuais ou automatizados, que compõem a medida emergencial. 
  +  Isso pode incluir mecanismos como [descarte de carga](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), [controle de utilização de solicitações](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) ou implementação de [degradação simples](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html) 
+  [REL05-BP02 Controlar a utilização de solicitações](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) 
+  [REL11-BP05 Usar estabilidade estática para evitar o comportamento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html) 

 **Documentos relacionados:** 
+ [Automatizar uma implantação prática e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+  [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering) 

 **Vídeos relacionados:** 
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability](https://www.youtube.com/watch?v=jUSYnRztttY)

# Gerenciamento de alterações
<a name="a-change-management"></a>

**Topics**
+ [CONFIABILIDADE 6. Como monitorar recursos de workload?](rel-06.md)
+ [CONFIABILIDADE 7. Como projetar sua workload para se adaptar às mudanças na demanda?](rel-07.md)
+ [CONFIABILIDADE 8. Como implementar uma alteração?](rel-08.md)

# CONFIABILIDADE 6. Como monitorar recursos de workload?
<a name="rel-06"></a>

Os logs e as métricas são uma ferramenta poderosa para saber a integridade de sua workload. Você pode configurar sua workload para monitorar logs e métricas e enviar notificações quando os limites forem ultrapassados ou em caso de eventos importantes. O monitoramento permite que sua workload reconheça quando os limites de baixa performance são ultrapassados ou quando há falhas, para que ela possa se recuperar automaticamente em resposta.

**Topics**
+ [REL06-BP01 Monitorar todos os componentes da workload (geração)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Definir e calcular as métricas (agregação)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 Envie notificações (processamento e emissão de alarmes em tempo real)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 Automatizar respostas (processamento e emissão de alarmes em tempo real)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 Análises](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 Realizar revisões regularmente](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 Monitorar o rastreamento completo das solicitações por meio de seu sistema](rel_monitor_aws_resources_end_to_end.md)

# REL06-BP01 Monitorar todos os componentes da workload (geração)
<a name="rel_monitor_aws_resources_monitor_resources"></a>

 monitore os componentes da carga de trabalho com o Amazon CloudWatch ou ferramentas de terceiros. Monitore os serviços da AWS com o painel do AWS Health. 

 Todos os componentes da carga de trabalho devem ser monitorados, incluindo front-end, lógica de negócios e níveis de armazenamento. Defina as principais métricas, descreva como extraí-las dos logs (se necessário) e defina limites de ativação para eventos de alarme correspondentes. Certifique-se de que as métricas sejam relevantes para os indicadores-chave de performance (KPIs) da workload e use métricas e logs para identificar os primeiros sinais de alerta de degradação do serviço. Por exemplo, uma métrica relacionada a resultados de negócios, como o número de pedidos processados ​​com êxito por minuto, pode indicar problemas de workload mais rapidamente do que uma métrica técnica, como a utilização da CPU. Use o painel do AWS Health para uma visualização personalizada da performance e da disponibilidade dos serviços da AWS subjacentes aos recursos da AWS. 

 O monitoramento na nuvem oferece novas oportunidades. A maioria dos provedores de nuvem desenvolveu ganchos personalizáveis ​​e pode entregar insights para ajudar você a monitorar várias camadas da workload. Serviços da AWS, como o Amazon CloudWatch, aplicam algoritmos estatísticos e de machine learning para analisar continuamente métricas de sistemas e de aplicações, determinam linhas de base normais e detectam anomalias com intervenção mínima do usuário. Os algoritmos de detecção de anomalias consideram a sazonalidade e as mudanças de tendência das métricas. 

 A AWS disponibiliza uma abundância de informações de monitoramento e de log para consumo, que podem ser usadas para definir métricas específicas de workload, processos de alteração sob demanda e adotar técnicas de machine learning, independentemente da experiência em ML. 

 Além disso, monitore todos os seus endpoints externos para garantir que eles sejam independentes de sua implementação de base. Este monitoramento ativo pode ser feito com transações sintéticas (às vezes chamadas de *canários de usuário*, mas que não devem ser confundido com implantações canário) que executam periodicamente um número de tarefas comuns que correspondem às ações realizadas pelos clientes da workload. Mantenha estas tarefas de curta duração e certifique-se de não sobrecarregar a workload durante o teste. O Amazon CloudWatch Synthetics permite [criar canários sintéticos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) para monitorar seus endpoints e APIs. Você também pode combinar os nós sintéticos do cliente canário com o console do AWS X-Ray para identificar quais canários sintéticos estão enfrentando problemas com erros, falhas ou taxas de controle de utilização para o período selecionado. 

 **Resultado desejado:** 

 Coletar e usar métricas críticas de todos os componentes da workload para garantir sua confiabilidade e a experiência ideal do usuário. Detectar que uma workload não está alcançando resultados de negócios permite que você declare rapidamente um desastre e se recupere de um incidente. 

 **Antipadrões comuns:** 
+  Monitorar apenas as interfaces externas com sua carga de trabalho. 
+  Não gerar métricas específicas de workload e confiar apenas nas métricas fornecidas pelos serviços da AWS usados pela sua workload. 
+  Usar apenas métricas técnicas na workload e não monitorar nenhuma métrica relacionada a KPIs não técnicos para os quais a workload contribui. 
+  Depender do tráfego de produção e de verificações de integridade simples para monitorar e avaliar o estado da workload. 

 **Benefícios do estabelecimento dessa prática recomendada:** O monitoramento em todos os níveis da workload permite prever e resolver problemas mais rapidamente nos componentes que a compõem. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

1.  **Habilite o registro em log quando disponível.** Os dados de monitoramento devem ser obtidos de todos os componentes das workloads. Ative o registro em log adicional, como os logs de acesso do S3, e habilite sua workload para registrar dados específicos da workload. Colete métricas para médias de CPU, E/S de rede e E/S de disco de serviços como o Amazon ECS, o Amazon EKS, o Amazon EC2, o Elastic Load Balancing, o AWS Auto Scaling e o Amazon EMR. Perceber [Serviços da AWS que publicam métricas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) para uma lista dos serviços da AWS que publicam métricas do CloudWatch. 

1.  **Revise todas as métricas padrão e explore quaisquer lacunas na coleta de dados.** Cada serviço gera métricas padrão. A coleta de métricas padrão permite que você entenda melhor as dependências entre os componentes da workload e como a confiabilidade e a performance destes componentes a afetam. Você também pode criar e [publicar suas próprias métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) para CloudWatch usando o AWS CLI ou uma API. Isso 

1.  **Avalie todas as métricas para decidir quais alertar para cada serviço da AWS na sua workload.** Você pode escolher selecionar um subconjunto de métricas que tenha um grande impacto na confiabilidade da workload. Focar em métricas e limites críticos permite refinar o número de alertas [de emergência](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) e pode ajudar a minimizar falso-positivos. 

1.  **Defina alertas e o processo de recuperação para a workload depois que o alerta for acionado.** A definição de alertas permite que você notifique, escalone e siga rapidamente as etapas necessárias para se recuperar de um incidente e atender ao seu objetivo de tempo de recuperação (RTO) prescrito. Você pode usar o [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) para invocar fluxos de trabalho automatizados e iniciar procedimentos de recuperação com base em limites definidos. 

1.  **Explore o uso de transações sintéticas para coletar dados relevantes sobre o estado das workloads.** O monitoramento sintético segue as mesmas rotas e realiza as mesmas ações que um cliente, possibilitado que você verifique continuamente a experiência do cliente, mesmo quando não há tráfego de clientes nas workloads. Ao usar [transações sintéticas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), você pode descobrir problemas antes que seus clientes o façam. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)

 **Documentos relacionados:** 
+  [Conceitos básicos do painel do AWS Health: integridade da sua conta](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) 
+  [Serviços da AWS que publicam métricas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
+  [Logs de acesso para o Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html) 
+  [Logs de acesso para seu application load balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html) 
+  [Acessar o Amazon CloudWatch Logs para o AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html) 
+  [Registro em log de acesso ao servidor do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html) 
+  [Habilite logs de acesso para o Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html) 
+  [Exportação de dados de log para o Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 
+  [Instalação do agente do CloudWatch em uma instância do Amazon EC2](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html) 
+  [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Uso de painéis do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Uso de métricas do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
+  [Uso de canários (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [O que é o Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 

   **Guias do usuário:** 
+  [Criação de uma trilha](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) 
+  [Monitoramento de métricas de memória e de disco para instâncias do Linux do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html) 
+  [Uso do CloudWatch Logs com instâncias de contêiner](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
+  [Logs de fluxo da VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html) 
+  [O que é o Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  [O que é o AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 

 **Blogs relacionados:** 
+  [Depuração com o Amazon CloudWatch Synthetics e o AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 

 **Exemplos e workshops relacionados:** 
+  [Laboratórios do AWS Well-Architected: excelência operacional: monitoramento de dependência](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/) 
+  [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Workshop de observabilidade](https://catalog.workshops.aws/observability/en-US) 

# REL06-BP02 Definir e calcular as métricas (agregação)
<a name="rel_monitor_aws_resources_notification_aggregation"></a>

 Armazene os dados de log e aplique filtros quando necessário para calcular métricas, como contagens de um evento de log específico ou latência calculada com base na data e hora dos eventos de log. 

 O Amazon CloudWatch e o Amazon S3 funcionam como camadas primárias de agregação e armazenamento. Para alguns serviços, como o AWS Auto Scaling e o Elastic Load Balancing, métricas padrão são fornecidas para carga de CPU ou latência média de solicitação em um cluster ou uma instância. Para serviços de streaming, como o VPC Flow Logs e o AWS CloudTrail, dados de evento são encaminhados ao CloudWatch Logs, e você precisa definir e aplicar filtros de métricas para extraí-las dos dados do evento. Isso fornece dados de séries temporais, que podem servir como entradas para alarmes do CloudWatch que você define para acionar alertas. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Defina e calcule as métricas (agregação). Armazene os dados de log e aplique filtros quando necessário para calcular métricas como contagens de um evento de log específico ou latência calculada com base na data e hora dos eventos de log 
  +  Os filtros de métrica definem os termos e os padrões a serem procurados nos dados de log à medida que são enviados para o CloudWatch Logs. O CloudWatch Logs usa esses filtros para transformar dados de log em métricas numéricas do CloudWatch, que você pode representar graficamente ou para as quais pode definir um alarme. 
    +  [Pesquisa e filtragem de dados de log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 
  +  Use um terceiro confiável para agregar logs. 
    +  Siga as instruções do terceiro. A maioria dos produtos de terceiros integra-se ao CloudWatch e ao Amazon S3. 
  +  Alguns serviços da AWS podem publicar logs diretamente no Amazon S3. Se seu principal requisito de logs for o armazenamento no Amazon S3, você poderá facilmente fazer com que o serviço que produz os logs os envie diretamente ao Amazon S3 sem configurar uma infraestrutura adicional. 
    +  [Envie logs diretamente ao Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Consultas de exemplo do Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Depuração com o Amazon CloudWatch Synthetics e o AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [Um workshop de observabilidade](https://observability.workshop.aws/) 
+  [Pesquisa e filtragem de dados de log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 
+  [Envie logs diretamente ao Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 
+  [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 

# REL06-BP03 Envie notificações (processamento e emissão de alarmes em tempo real)
<a name="rel_monitor_aws_resources_notification_monitor"></a>

Quando as organizações detectam possíveis problemas, elas enviam notificações e alertas em tempo real para a equipe e os sistemas apropriados para responder de forma rápida e eficaz a esses problemas.

 **Resultado desejado:** respostas rápidas a eventos operacionais são possíveis por meio da configuração de alarmes relevantes com base nas métricas de serviços e aplicações. Quando os limites do alarme são violados, o pessoal e os sistemas apropriados são notificados para que possam resolver os problemas subjacentes. 

 **Antipadrões comuns:** 
+ Configuração de alarmes com um limite excessivamente alto, resultando em falha no envio de notificações vitais.
+ Configurar alarmes com um limite muito baixo, ocasionando inatividade diante de alertas importantes devido ao ruído de notificações excessivas.
+  Não atualizar os alarmes e seu limite quando o uso muda. 
+  Para alarmes mais bem abordados por meio de ações automatizadas, enviar a notificação ao pessoal em vez de gerar a ação automatizada gera o envio excessivo de notificações. 

 **Benefícios de estabelecer esta prática recomendada:** O envio de notificações e alertas em tempo real para o pessoal e os sistemas apropriados permite a detecção precoce de problemas e respostas rápidas aos incidentes operacionais. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 As workloads devem ser equipadas com processamento e alarmes em tempo real para melhorar a detectabilidade de problemas que possam afetar a disponibilidade da aplicação e servir como gatilhos para respostas automatizadas. As organizações podem realizar processamento e alarmes em tempo real criando alertas com métricas definidas para receber notificações sempre que eventos significativos ocorrerem ou quando uma métrica ultrapassar um limite. 

 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) permite criar [alarmes de métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) e compostos usando alarmes do CloudWatch com base em limite estático, detecção de anomalias e outros critérios. Para obter mais detalhes sobre os tipos de alarme que você pode configurar usando o CloudWatch, consulte a [seção de alarmes da documentação do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). 

 É possível criar visualizações personalizadas de métricas e alertas dos recursos da AWS para as equipes usando [painéis do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). As páginas iniciais personalizáveis no console do CloudWatch permitem que você monitore seus recursos em uma única visualização em várias regiões. 

 Os alarmes podem realizar uma ou mais ações, como enviar uma notificação a um [tópico do Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), realizando uma ação do [Amazon EC2](https://aws.amazon.com/ec2/) ou do [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) , ou [criando um OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) ou [incidente](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) no AWS Systems Manager. 

 O Amazon CloudWatch usa o [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) para enviar notificações quando o alarme muda de estado, fornecendo a entrega de mensagens dos publicadores (produtores) para os assinantes (consumidores). Para obter mais detalhes sobre como configurar notificações do Amazon SNS, consulte [Configuring Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html). 

 O CloudWatch envia eventos do [EventBridge](https://aws.amazon.com/eventrbridge/) [segurança](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html) sempre que um alarme do CloudWatch é criado, atualizado, excluído ou o estado muda. É possível usar o EventBridge com esses eventos para criar regras que realizam ações, como enviar uma notificação sempre que o estado de um alarme mudar ou acionar eventos automaticamente na conta usando o [Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html). 

** Quando você deve usar o EventBridge ou o Amazon SNS? **

 Tanto o EventBridge quanto o Amazon SNS podem ser usados para desenvolver aplicações orientadas a eventos, e sua escolha dependerá de suas necessidades específicas. 

 O Amazon EventBridge é recomendado quando você deseja criar uma aplicação que reaja a eventos de suas próprias aplicações, aplicações SaaS e serviços da AWS. O EventBridge é o único serviço baseado em eventos que se integra diretamente com parceiros SaaS de terceiros. O EventBridge também ingere automaticamente eventos de mais de 200 serviços da AWS sem exigir que os desenvolvedores criem recursos em suas contas. 

 O EventBridge usa uma estrutura definida baseada em JSON para eventos e ajuda você a criar regras que são aplicadas em todo o corpo do evento para selecionar eventos a serem encaminhados a um [destino](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html). O EventBridge no momento é compatível com mais de vinte serviços da AWS como destinos, incluindo [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html), o [Amazon SQS](https://aws.amazon.com/sqs/), Amazon SNS, [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/)e o [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/). 

 O Amazon SNS é recomendado para aplicações que precisam de alta distribuição (milhares ou milhões de endpoints). Um padrão comum que vemos é que os clientes usam o Amazon SNS como destino para a regra a fim de filtrar os eventos de que precisam e distribuí-los para vários endpoints. 

 As mensagens não são estruturadas e podem estar em qualquer formato. O Amazon SNS permite o encaminhamento de mensagens a seis tipos diferentes de destinos, incluindo Lambda, Amazon SQS, endpoints HTTP/S, SMS, push de dispositivos móveis e e-mail. A latência típica do Amazon SNS [é inferior a 30 milissegundos](https://aws.amazon.com/sns/faqs/). Uma ampla variedade de serviços da AWS envia ao Amazon SNS mensagens configurando o serviço para fazer isso (mais de trinta, incluindo o Amazon EC2, o [Amazon S3](https://aws.amazon.com/s3/)e o [Amazon RDS](https://aws.amazon.com/rds/)). 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Crie um alarme usando [alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). 

   1.  Um alarme de métrica monitora uma única métrica do CloudWatch ou uma expressão dependente de métricas do CloudWatch. O alarme inicia uma ou mais ações com base no valor da métrica ou expressão em comparação com um limite em vários intervalos de tempo. A ação pode consistir em enviar uma notificação a um [tópico do Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), realizando uma ação do [Amazon EC2](https://aws.amazon.com/ec2/) ou do [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) , ou [criando um OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) ou [incidente](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) no AWS Systems Manager. 

   1.  Um alarme composto consiste em uma expressão de regra que considera as condições de alarme de outros alarmes que você criou. O alarme composto só entra no estado de alarme se todas as condições da regra forem atendidas. Os alarmes especificados na expressão da regra de um alarme composto podem incluir alarmes de métricas e outros alarmes compostos. Alarmes compostos podem enviar notificações do Amazon SNS quando o estado muda e podem criar Systems Manager [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) ou [incidentes](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) quando entram no estado de alarme, mas não conseguem realizar ações do Amazon EC2 ou do Auto Scaling. 

1.  Configure o [Notificações do Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html). Ao criar um alarme do CloudWatch, é possível incluir um tópico do Amazon SNS para enviar uma notificação quando o alarme mudar de estado. 

1.  [Crie regras no EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) que corresponde aos alarmes do CloudWatch especificados. Cada regra é compatível com vários destinos, incluindo funções do Lambda. Por exemplo, você pode definir um alarme que é iniciado quando o espaço disponível em disco está acabando, o que aciona uma função do Lambda por meio de uma regra do EventBridge para limpar o espaço. Para obter mais detalhes sobre destinos do EventBridge, consulte [EventBridge targets](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [REL06-BP01 Monitorar todos os componentes da workload (geração)](rel_monitor_aws_resources_monitor_resources.md) 
+  [REL06-BP02 Definir e calcular as métricas (agregação)](rel_monitor_aws_resources_notification_aggregation.md) 
+  [REL12-BP01 Usar playbooks para investigar falhas](rel_testing_resiliency_playbook_resiliency.md) 

 **Documentos relacionados:** 
+ [ Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ CloudWatch Logs insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+  [Using Amazon CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Using Amazon CloudWatch dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Using Amazon CloudWatch metrics (Uso de métricas do Amazon CloudWatch)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
+ [ Setting up Amazon SNS notifications ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [ detecção de anomalias do CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ CloudWatch Logs data protection ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/protect-sensitive-log-data-types.html)
+ [ Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [ Amazon Simple Notification Service ](https://aws.amazon.com/sns/)

 **Vídeos relacionados:** 
+ [ reinvent 2022 observability videos (Vídeos sobre observabilidade do AWS re:Invent 2022) ](https://www.youtube.com/results?search_query=reinvent+2022+observability)
+ [AWS re:Invent 2022 - Observability best practices at Amazon (AWS re:Invent 2022: práticas recomendadas de observabilidade na Amazon) ](https://www.youtube.com/watch?v=zZPzXEBW4P8)

 **Exemplos relacionados:** 
+  [Um workshop de observabilidade](https://observability.workshop.aws/) 
+ [ Amazon EventBridge to AWS Lambda with feedback control by Amazon CloudWatch Alarms ](https://serverlessland.com/patterns/cdk-closed-loop-serverless-control-pattern)

# REL06-BP04 Automatizar respostas (processamento e emissão de alarmes em tempo real)
<a name="rel_monitor_aws_resources_automate_response_monitor"></a>

 Use a automação para executar uma ação quando um evento é detectado, por exemplo, para substituir componentes com falha. 

 O processamento automatizado de alarmes em tempo real é implementado para que os sistemas possam tomar medidas corretivas rapidamente e tentar evitar falhas ou degradação dos serviços quando os alarmes são acionados. As respostas automatizadas a alarmes podem incluir a substituição de componentes com falha, o ajuste da capacidade computacional, o redirecionamento do tráfego para hosts, zonas de disponibilidade ou outras regiões íntegras e a notificação dos operadores. 

 **Resultado desejado:** os alarmes em tempo real são identificados, e o processamento automatizado dos alarmes é configurado para invocar as ações apropriadas realizadas para manter os objetivos de nível de serviço e os acordos de serviço (SLAs). A automação pode variar de atividades de autorrecuperação de componentes individuais a failover de todo o site. 

 **Antipadrões comuns:** 
+  Não ter um inventário ou catálogo claro dos principais alarmes em tempo real. 
+  Não haver respostas automatizadas para alarmes essenciais (por exemplo, quando a computação está quase esgotada, ocorre o ajuste de escala automático). 
+  Usar ações contraditórias de resposta a alarmes. 
+  Não haver procedimentos operacionais padrão (SOPs) para os operadores seguirem ao receberem notificações de alerta. 
+  Não monitorar as alterações da configuração, pois alterações não detectadas podem causar tempo de inatividade nas workloads. 
+  Não haver uma estratégia para desfazer alterações não intencionais da configuração. 

 **Benefícios do estabelecimento desta prática recomendada: ** a automatização do processamento de alarmes pode melhorar a resiliência do sistema. O sistema executa ações corretivas automaticamente, reduzindo as atividades manuais que permitem intervenções humanas sujeitas a erros. A workload opera, atende às metas de disponibilidade e reduz a interrupção do serviço. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Para gerenciar alertas com eficiência e automatizar as respectivas respostas, categorize os alertas com base em sua criticidade e impacto, documente os procedimentos de resposta e planeje as respostas antes das tarefas de classificação. 

 Identifique tarefas que exigem ações específicas (geralmente detalhadas em runbooks) e examine todos os runbooks e manuais para determinar as tarefas que podem ser automatizadas. Geralmente, se for possível definir ações, elas poderão ser automatizadas. Se não for possível automatizar as ações, documente as etapas manuais em um SOP e treine os operadores a respeito. Conteste continuamente os processos manuais em busca de oportunidades de automação em que seja possível estabelecer e manter um plano para automatizar as respostas a alertas. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  **Criar um inventário de alarmes:** para obter uma lista de todos os alarmes, é possível utilizar a [AWS CLI](https://aws.amazon.com/cli/) usando o comando do [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) `[describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html)`. Dependendo de quantos alarmes você configurou, talvez seja necessário usar paginação para recuperar um subconjunto de alarmes para cada chamada ou, alternativamente, utilizar o AWS SDK para obter os alarmes [usando uma chamada de API](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-describing-alarms.html). 

1.  **Documentar todas as ações do alarme: ** atualize um runbook com todos os alarmes e as respectivas ações, independentemente de serem manuais ou automatizados. O [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html)fornece runbooks predefinidos. Para obter mais informações sobre runbooks, consulte [Working with runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html). Para obter detalhes sobre como visualizar o conteúdo do runbook, consulte [View runbook content](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html#view-automation-json). 

1.  **Configurar e gerenciar ações de alarmes:** para qualquer um dos alarmes que exijam uma ação, especifique a [ação automatizada usando o SDK do CloudWatch](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html). Por exemplo, é possível alterar o estado das instâncias do Amazon EC2 automaticamente com base em um alarme do CloudWatch criando e ativando ações em um alarme ou desativando ações em um alarme. 

    Também é possível usar o [Amazon EventBridge](https://aws.amazon.com/eventbridge/) para responder automaticamente a eventos do sistema, como problemas de disponibilidade de aplicações ou alterações de recursos. Você pode criar regras para indicar em quais eventos tem interesse e as ações a serem executadas quando um evento corresponder a uma regra. As ações que podem ser iniciadas automaticamente incluem invocar um perfil do [AWS Lambda](https://aws.amazon.com/lambda/), invocar o `Run Command` do [Amazon EC2](https://aws.amazon.com/ec2/), transmitir o evento para o [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) e visualizar o documento [Automatizar o Amazon EC2 usando o EventBridge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html). 

1.  **Procedimentos operacionais padrão (SOPs):** com base nos componentes da aplicação, o [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) recomenda vários [modelos de SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/sops.html). É possível usar esses SOPs para documentar todos os processos que um operador deve seguir caso um alerta seja emitido. Também é possível [estruturar um SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/building-sops.html) com base nas recomendações do Resilience Hub, caso em que você precisa de uma aplicação do Resilience Hub com uma política de resiliência associada, bem como de uma avaliação histórica de resiliência em relação a essa aplicação. As recomendações para o SOP são produzidas pela avaliação de resiliência. 

    O Resilience Hub trabalha com o Systems Manager para automatizar as etapas dos SOPs, fornecendo vários [documentos do SSM](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-custom-ssm-doc.html) que podem ser usados como base para esses SOPs. Por exemplo, o Resilience Hub pode recomendar um SOP para adicionar espaço em disco com base em um documento de automação existente do SSM. 

1.  **Realizar ações automatizadas usando o Amazon DevOps Guru:** é possível usar o [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) para monitorar automaticamente recursos da aplicação em busca de comportamento anômalo e fornecer recomendações direcionadas para acelerar o tempo de identificação e de correção de problemas. Com o DevOps Guru, é possível monitorar fluxos de dados operacionais quase em tempo real de várias fontes, incluindo as métricas do Amazon CloudWatch, o [AWS Config](https://aws.amazon.com/config/), o [AWS CloudFormation](https://aws.amazon.com/cloudformation/) e o [AWS X-Ray](https://aws.amazon.com/xray/). Também é possível usar o DevOps Guru para criar [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) no OpsCenter e enviar eventos ao [EventBridge para automação adicional](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-eventbridge.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL06-BP01 Monitorar todos os componentes da workload (geração)](rel_monitor_aws_resources_monitor_resources.md) 
+  [REL06-BP02 Definir e calcular as métricas (agregação)](rel_monitor_aws_resources_notification_aggregation.md) 
+  [REL06-BP03 Envie notificações (processamento e emissão de alarmes em tempo real)](rel_monitor_aws_resources_notification_monitor.md) 
+  [REL08-BP01 Usar runbooks para atividades padrão, como implantação](rel_tracking_change_management_planned_changemgmt.md) 

 **Documentos relacionados:** 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [Creating an EventBridge Rule That Triggers on an Event from an AWS Resource](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html) 
+  [Um workshop de observabilidade](https://observability.workshop.aws/) 
+  [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [What is Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  [Trabalhar com documentos de automação (playbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 

 **Vídeos relacionados:** 
+ [AWS re:Invent 2022: Práticas recomendadas de observabilidade na Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8)
+ [AWS re:Invent 2020: Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [ Introduction to AWS Resilience Hub](https://www.youtube.com/watch?v=_OTTCOjWqPo)
+ [ Criar sistemas de tickets personalizados para notificações do Amazon DevOps Guru ](https://www.youtube.com/watch?v=Mu8IqWVGUfg)
+ [ Enable Multi-Account Insight Aggregation with Amazon DevOps Guru ](https://www.youtube.com/watch?v=MHezNcTSTbI)

 **Exemplos relacionados:** 
+ [ Reliability Workshops ](https://wellarchitectedlabs.com/reliability/)(Workshops sobre confiabilidade)
+ [ Workshop do Amazon CloudWatch e do Systems Manager ](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US)

# REL06-BP05 Análises
<a name="rel_monitor_aws_resources_storage_analytics"></a>

 colete arquivos de log e históricos de métricas e analise-os para obter tendências mais abrangentes e informações sobre a carga de trabalho. 

 O Amazon CloudWatch Logs oferece suporte a uma [linguagem de consulta simples, mas poderosa](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) que você pode usar para analisar dados de log. O Amazon CloudWatch Logs também oferece suporte a assinaturas que permitem que os dados fluam perfeitamente ao Amazon S3, onde você pode usar o ou o Amazon Athena para consultar esses dados. Ele oferece suporte a consultas em uma grande variedade de formatos. Perceber [Formatos de dados e SerDes compatíveis](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) no guia do usuário do Amazon Athena para obter mais informações. Para análise de conjuntos enormes de arquivos de log, você pode executar um cluster do Amazon EMR para executar análises em escala de petabytes. 

 Existem várias ferramentas fornecidas por parceiros da AWS e por terceiros que permitem agregação, processamento, armazenamento e estudo analítico. Essas ferramentas incluem New Relic, Splunk, Loggly, Logstash, CloudHealth e Nagios. Porém, a geração fora dos registros do aplicativo e do sistema é única para cada provedor de nuvem e costuma ser única para cada serviço. 

 Uma parte do processo de monitoramento que costuma ser negligenciada é o gerenciamento de dados. Você precisa determinar os requisitos de retenção para monitorar os dados e então aplicar as políticas de ciclo de vida de acordo. O Amazon S3 oferece suporte ao gerenciamento de ciclo de vida no nível do bucket do S3. Esse gerenciamento de ciclo de vida pode ser aplicado de modo diferente a diferentes caminhos no bucket. Mais perto do fim do ciclo de vida, você pode fazer a transição dos dados ao Amazon Glacier para armazenamento de longo prazo e posterior expiração após o fim do período de retenção. A classe de armazenamento S3 Intelligent-Tiering foi projetada para otimizar custos movendo automaticamente dados para o nível de acesso mais econômico, sem impacto na performance ou sobrecarga operacional. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  O CloudWatch Logs Insights permite pesquisar e analisar dinamicamente seus dados de log no Amazon CloudWatch Logs. 
  +  [Análise de dados de log com o CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
  +  [Consultas de exemplo do Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 
+  Use o Amazon CloudWatch Logs para enviar logs para o Amazon S3, onde você pode usar o Amazon Athena para consultar dados. 
  +  [Como analiso meus logs de acesso ao servidor do Amazon S3 usando o Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) 
    +  Crie uma política de ciclo de vida do S3 para o bucket de logs de acesso ao seu servidor. Configure a política de ciclo de vida para remover periodicamente os arquivos de log. Esse procedimento reduz a quantidade de dados que o Athena analisa em cada consulta. 
      +  [Como faço para criar uma política de ciclo de vida de um bucket do S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Consultas de exemplo do Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Análise de dados de log com o CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
+  [Depuração com o Amazon CloudWatch Synthetics e o AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [Como faço para criar uma política de ciclo de vida de um bucket do S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) 
+  [Como analiso meus logs de acesso ao servidor do Amazon S3 usando o Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) 
+  [Um workshop de observabilidade](https://observability.workshop.aws/) 
+  [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 

# REL06-BP06 Realizar revisões regularmente
<a name="rel_monitor_aws_resources_review_monitoring"></a>

 Revise frequentemente a implementação do monitoramento da workload e atualize-a com base em eventos e alterações significativos. 

 O monitoramento eficaz é orientado pelas principais métricas de negócios. Certifique-se de que essas métricas sejam acomodadas em sua carga de trabalho à medida que as prioridades de negócios mudam. 

 Auditar seu monitoramento ajuda a garantir que você saiba quando um aplicativo está atingindo as respectivas metas de disponibilidade. A análise da causa raiz requer a capacidade de descobrir o que aconteceu quando ocorreram falhas. A AWS fornece serviços que permitem acompanhar o estado dos seus serviços durante um incidente: 
+  **Amazon CloudWatch Logs:** você pode armazenar seus logs nesse serviço e inspecionar seu conteúdo. 
+  **Amazon CloudWatch Logs Insights**: é um serviço totalmente gerenciado que permite analisar logs massivos em segundos. Ele oferece consultas e visualizações rápidas e interativas.  
+  **AWS Config:** você pode ver qual infraestrutura da AWS estava em uso em diferentes momentos. 
+  **AWS CloudTrail:** você pode ver quais APIs da AWS foram invocadas, a que horas e por qual entidade principal. 

 Na AWS, realizamos uma reunião semanal para [revisar a performance operacional](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) e para compartilhar aprendizados entre as equipes. Como há tantas equipes na AWS, criamos [A roda](https://aws.amazon.com/blogs/opensource/the-wheel/) para escolher aleatoriamente uma carga de trabalho para revisão. Estabelecer um ritmo regular para análises de performance operacional e compartilhamento de conhecimento aprimora sua capacidade de obter uma performance superior de suas equipes operacionais. 

 **Antipadrões comuns:** 
+  Coletar apenas as métricas padrão. 
+  Definir uma estratégia de monitoramento e nunca revisá-la. 
+  Não analisar o monitoramento quando alterações importantes são implantadas. 

 **Benefícios do estabelecimento dessa prática recomendada:** A revisão regular do monitoramento permite a antecipação de possíveis problemas, em vez de reagir a notificações quando um problema previsto realmente ocorrer. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Crie vários painéis para a workload. Você deve ter um painel superior com as principais métricas de negócios e as métricas técnicas identificadas como as mais relevantes à integridade projetada da carga de trabalho conforme a variação do uso. Você também deve ter painéis para vários níveis e dependências da aplicação que podem ser inspecionados. 
  +  [Uso de painéis do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  Programe e realize revisões regulares dos painéis da workload. Realize uma inspeção regular dos painéis. Você pode ter graus diferentes de profundidade para a inspeção. 
  +  Inspecione as tendências nas métricas. Compare os valores das métricas com os valores históricos para ver se há tendências que possam indicar algo que precise de investigação. Exemplos disso incluem: aumento da latência, diminuição da função principal de negócios e aumento das respostas a falhas. 
  +  Verifique se há exceções ou anomalias nas suas métricas. As médias ou os valores medianos podem mascarar as exceções e as anomalias. Examine os valores mais altos e mais baixos durante o período e investigue as causas das pontuações extremas. À medida que você continua a eliminar essas causas, a redução da definição de extremo permite melhorar cada vez mais a consistência da performance da workload. 
  +  Procure mudanças bruscas no comportamento. Uma mudança imediata na quantidade ou na direção de uma métrica pode indicar que houve uma alteração na aplicação ou fatores externos aos quais você talvez precise adicionar outras métricas para acompanhar. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Consultas de exemplo do Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Depuração com o Amazon CloudWatch Synthetics e o AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [Um workshop de observabilidade](https://observability.workshop.aws/) 
+  [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Uso de painéis do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 

# REL06-BP07 Monitorar o rastreamento completo das solicitações por meio de seu sistema
<a name="rel_monitor_aws_resources_end_to_end"></a>

Rastreie as solicitações à medida que elas são processadas por meio de componentes de serviço para que as equipes de produto possam analisar e depurar problemas com maior facilidade e melhorar a performance.

 **Resultado desejado:** As workloads com rastreamento abrangente em todos os componentes são fáceis de depurar, o que melhora [o tempo médio até a resolução](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html) (MTTR) de erros e latência simplificando a descoberta da causa raiz. O rastreamento completo reduz o tempo necessário para descobrir os componentes afetados e detalhar as causas raiz dos erros ou da latência. 

 **Antipadrões comuns:** 
+  O rastreamento é usado para alguns componentes, mas não para todos. Por exemplo, sem rastrear o AWS Lambda, as equipes podem não entender claramente a latência causada por partidas a frio em uma workload com picos. 
+  Canários sintéticos ou monitoramento de usuário real (RUM) não são configurados com rastreamento. Sem canários ou RUM, a telemetria de interação com o cliente é omitida da análise de rastreamento, gerando um perfil de performance incompleto. 
+  As workloads híbridas incluem ferramentas de rastreamento nativas da nuvem e de terceiros, mas ainda não foram tomadas medidas eletivas e integram totalmente uma única solução de rastreamento. Com base na solução de rastreamento escolhida, os SDKs de rastreamento nativos de nuvem devem ser usados para instrumentar componentes que não são nativos de nuvem ou ferramentas de terceiros devem ser configuradas para ingerir a telemetria de rastreamento nativa de nuvem. 

 **Benefícios de estabelecer esta prática recomendada:** Quando as equipes de desenvolvimento são alertadas sobre problemas, elas podem ter uma visão completa das interações dos componentes do sistema, incluindo a correlação componente por componente com registros em log, performance e falhas. Como o rastreamento facilita a identificação visual das causas raiz, menos tempo é gasto na investigação delas. As equipes que entendem detalhadamente as interações dos componentes tomam decisões melhores e mais rápidas ao resolver problemas. Decisões como quando invocar o failover de recuperação de desastres (DR) ou onde melhor implementar estratégias de autorrecuperação podem ser aprimoradas com a análise de rastreamentos de sistemas e aumentar a satisfação do cliente com seus serviços. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 As equipes que operam aplicações distribuídas podem usar ferramentas de rastreamento para estabelecer um identificador de correlação, coletar rastreamentos de solicitações e criar mapas de serviço dos componentes conectados. Todos os componentes da aplicação devem ser incluídos nos rastreamentos de solicitações, incluindo clientes de serviços, gateways de middleware e barramentos de eventos, componentes computacionais e armazenamento, incluindo armazenamentos de chave-valor e bancos de dados. Inclua canários sintéticos e monitoramento de usuários reais em sua configuração de rastreamento completo a fim de medir as interações remotas com clientes e a latência, para que você possa avaliar com precisão a performance de seus sistemas em relação aos seus objetivos e acordos de serviço. 

 Você pode usar o [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) e os [serviços de instrumentação de monitoramento de aplicações do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) para oferecer uma visão completa das solicitações à medida que elas passam por sua aplicação. O X-Ray coleta a telemetria da aplicação e permite que você a visualize e filtre em payloads, funções, rastreamentos, serviços, APIs e pode ser ativada para componentes do sistema com pouco ou nenhum código. O monitoramento de aplicações do CloudWatch inclui o ServiceLens para integrar seus rastreamentos a métricas, logs e alarmes. O monitoramento de aplicações do CloudWatch também inclui sintéticos a fim de monitorar seus endpoints e APIs, bem como monitoramento de usuários reais para instrumentar seus clientes de aplicações web. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Use o AWS X-Ray em todos os serviços nativos compatíveis, como [Amazon S3, AWS Lambda e Amazon API Gateway](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html). Esses serviços da AWS permitem ao X-Ray alternar a configuração usando a infraestrutura como código, AWS SDKs ou o Console de gerenciamento da AWS. 
+  Aplicações de instrumentos [AWS Distro for Open Telemetry e X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html) ou agentes de coleta de terceiros. 
+ Revise o [Guia do desenvolvedor do AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) para implementação específica da linguagem de programação. Essas seções da documentação detalham como instrumentar solicitações HTTP, consultas SQL e outros processos específicos de sua linguagem de programação de aplicações.
+  Use o rastreamento do X-Ray para [Canários sintéticos do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) e os [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) para analisar o caminho da solicitação de seu cliente de usuário final por meio de sua infraestrutura downstream da AWS. 
+  Configure métricas e alarmes do CloudWatch com base na integridade dos recursos e na telemetria canário para que as equipes sejam alertadas sobre problemas rapidamente e, depois, possam se aprofundar em rastreamentos e mapas de serviços com o ServiceLens. 
+  Habilite a integração do X-Ray a ferramentas de rastreamento de terceiros, como [Datadog](https://docs.datadoghq.com/tracing/guide/serverless_enable_aws_xray/), [New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-x-ray-monitoring-integration/)ou [Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-service-metrics) se você estiver usando ferramentas de terceiros para sua solução de rastreamento principal. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL06-BP01 Monitorar todos os componentes da workload (geração)](rel_monitor_aws_resources_monitor_resources.md) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md) 

 **Documentos relacionados:** 
+  [O que é o AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+ [ Amazon CloudWatch: Monitoramento de aplicações ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)
+  [Depuração com o Amazon CloudWatch Synthetics e o AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+ [ Integrar o AWS X-Ray a outros serviços da AWS](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)
+ [AWS Distro for OpenTelemetry e AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)
+ [ Amazon CloudWatch: uso do monitoramento sintético ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [ Amazon CloudWatch: usar o CloudWatch RUM ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [ Configurar o canário sintético do Amazon CloudWatch e o alarme do Amazon CloudWatch ](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/set-up-amazon-cloudwatch-synthetics-canary-and-amazon-cloudwatch-alarm.html)
+ [ Disponibilidade e além: compreensão e melhoria da resiliência de sistemas distribuídos na AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)

 **Exemplos relacionados:** 
+ [ Um workshop de observabilidade ](https://catalog.workshops.aws/observability/en-US)

 **Vídeos relacionados:** 
+ [AWS re:Invent 2022 - How to monitor applications across multiple accounts (re:Invent 2022: Como monitorar aplicações em várias contas) ](https://www.youtube.com/watch?v=kFGOkywu-rw)
+ [ How to Monitor your AWS Applications (Como monitorar suas aplicações da AWS) ](https://www.youtube.com/watch?v=UxWU9mrSbmA)

 **Ferramentas relacionadas:** 
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/pm/cloudwatch/)
+ [ Amazon Route 53 ](https://aws.amazon.com/route53/)

# CONFIABILIDADE 7. Como projetar sua workload para se adaptar às mudanças na demanda?
<a name="rel-07"></a>

Uma carga de trabalho escalável oferece elasticidade para adicionar ou remover recursos automaticamente para que atendam melhor à demanda atual a qualquer momento.

**Topics**
+ [REL07-BP01 Usar a automação ao obter ou escalar recursos](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 Obter recursos após a detecção de danos em uma workload](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 Obter recursos após a detecção de que mais recursos são necessários para uma workload](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 Fazer o teste de carga da sua workload](rel_adapt_to_changes_load_tested_adapt.md)

# REL07-BP01 Usar a automação ao obter ou escalar recursos
<a name="rel_adapt_to_changes_autoscale_adapt"></a>

 Ao substituir recursos danificados ou escalar sua workload, automatize o processo por meio dos serviços gerenciados pela AWS, como o Amazon S3 e o AWS Auto Scaling. Você também pode usar ferramentas de terceiros e os AWS SDKs para automatizar a escalabilidade. 

 Os serviços gerenciados pela AWS incluem o Amazon S3, o Amazon CloudFront, o AWS Auto Scaling, o AWS Lambda, o Amazon DynamoDB, o AWS Fargate e o Amazon Route 53. 

 O AWS Auto Scaling permite detectar e substituir instâncias danificadas. Ele também permite criar planos de escalabilidade para recursos, incluindo instâncias e frotas Spot do [Amazon EC2](https://aws.amazon.com/ec2/) , tarefas do [Amazon ECS](https://aws.amazon.com/ecs/) tabelas e índices do [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) e réplicas do [Amazon Aurora](https://aws.amazon.com/aurora/) . 

 Ao escalar instâncias do EC2, certifique-se de usar várias zonas de disponibilidade (de preferência, pelo menos três) e adicione ou remova capacidade para manter o equilíbrio entre essas zonas de disponibilidade. Tarefas do ECS ou pods do Kubernetes (ao usar o Amazon Elastic Kubernetes Service) também devem ser distribuídos em várias zonas de disponibilidade. 

 Ao usar o AWS Lambda, as instâncias são escaladas automaticamente. Sempre que uma notificação de evento é recebida para sua função, o AWS Lambda localiza rapidamente a capacidade livre dentro de sua frota de computação e executa seu código até a simultaneidade alocada. Você precisa se certificar de que a simultaneidade necessária esteja configurada no Lambda específico e no seu Service Quotas. 

 O Amazon S3 escala automaticamente para lidar com altas taxas de solicitação. Por exemplo, seu aplicativo pode atingir pelo menos 3.500 solicitações PUT/COPY/POST/DELETE ou 5.500 solicitações GET/HEAD por segundo por prefixo em um bucket. Não há limites para o número de prefixos em um bucket. Você pode aumentar a performance de leitura ou gravação paralelizando as leituras. Por exemplo, se você criar 10 prefixos em um bucket do Amazon S3 para paralelizar leituras, poderá escalar sua performance de leitura para 55 mil solicitações de leitura por segundo. 

 Configure e use o Amazon CloudFront ou uma rede de entrega de conteúdo (CDN) confiável. Uma CDN pode fornecer tempos mais rápidos de resposta ao usuário final e atender às solicitações de conteúdo do cache, reduzindo a necessidade de escalar a workload. 

 **Antipadrões comuns:** 
+  Implementar grupos de Auto Scaling para autorreparação, mas não implementar elasticidade. 
+  Usar a escalabilidade automática para responder a grandes aumentos no tráfego. 
+  Implantar aplicativos altamente com estado, eliminando a opção de elasticidade. 

 **Benefícios do estabelecimento dessa prática recomendada:** A automação elimina a possibilidade de erros manuais na implantação e no descomissionamento de recursos. A automação remove o risco de custos excedentes e de negação de serviço decorrentes da lentidão na resposta às necessidades de implantação ou de descomissionamento. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Configure e use o AWS Auto Scaling. Ele monitora seus aplicativos e ajusta automaticamente a capacidade para manter uma performance estável e previsível com o menor custo possível. Ao usar o AWS Auto Scaling, você pode configurar a escalabilidade da aplicação para vários recursos em diversos serviços. 
  +  [O que é o AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) 
    +  Configure o Auto Scaling nas instâncias do Amazon EC2 e frotas spot, nas tarefas do Amazon ECS, nas tabelas e índices do Amazon DynamoDB, nas réplicas do Amazon Aurora e nos dispositivos do AWS Marketplace, conforme aplicável. 
      +  [Gerenciamento da capacidade de throughput de modo automático com o DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
        +  Use as operações de API de serviço para especificar alarmes, políticas de escalabilidade e tempos de aquecimento e de resfriamento. 
+  Use o Elastic Load Balancing. Os load balancers podem distribuir a carga por caminho ou por conectividade de rede. 
  +  [O que é o Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
    +  O Application Load Balancers pode distribuir a carga por caminho. 
      +  [O que é um Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
        +  Configure um Application Load Balancer para distribuir o tráfego para diferentes workloads com base no caminho sob o nome de domínio. 
        +  É possível usar os Application Load Balancers para distribuir as cargas de maneira integrada ao AWS Auto Scaling para gerenciar a demanda. 
          +  [Uso de um balanceador de carga com um grupo de Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 
    +  Os Network Load Balancers podem distribuir a carga por conexão. 
      +  [O que é um Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
        +  Configure um Network Load Balancer para distribuir o tráfego para cargas de trabalho diferentes por meio do TCP ou para ter um conjunto constante de endereços IP para a carga de trabalho. 
        +  É possível usar os Network Load Balancers para distribuir as cargas de maneira integrada ao AWS Auto Scaling para gerenciar a demanda. 
+  Use um provedor DNS altamente disponível. Nomes DNS permitem que os usuários insiram nomes, em vez de endereço IP, para acessar suas workloads e distribuem essas informações a um escopo definido, em geral, globalmente para usuários da workload. 
  +  Use o Amazon Route 53 ou um provedor DNS confiável. 
    +  [O que é o Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
  +  Use o Route 53 para gerenciar as distribuições e os balanceadores de carga do CloudFront. 
    +  Determine os domínios e subdomínios que serão gerenciados. 
    +  Crie conjuntos de registros adequados com os registros ALIAS ou CNAME. 
      +  [Trabalhando com registros](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) 
+  Use a rede global da AWS para otimizar o caminho dos usuários às aplicações. O AWS Global Accelerator monitora continuamente a integridade dos endpoints da aplicação e redireciona o tráfego para endpoints íntegros em menos de 30 segundos. 
  +  O AWS Global Accelerator é um serviço que melhora a disponibilidade e a performance das aplicações com usuários locais ou globais. Ele fornece endereços IP estáticos que atuam como um ponto de entrada fixo para os endpoints da aplicação em uma ou várias Regiões da AWS, como os Application Load Balancers, os Network Load Balancers ou as instâncias do Amazon EC2. 
    +  [O que é o AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  Configure e use o Amazon CloudFront ou uma rede de entrega de conteúdo (CDN) confiável. Uma rede de entrega de conteúdo pode fornecer tempos mais rápidos de resposta ao usuário final e atender às solicitações de conteúdo que podem causar escalabilidade desnecessária das suas workloads. 
  +  [O que é o Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 
    +  Configure as distribuições do Amazon CloudFront para suas workloads ou use uma CDN de terceiros. 
      +  Você pode limitar o acesso às workloads para que elas sejam acessíveis somente pelo CloudFront usando os intervalos de IPs para o CloudFront nos seus grupos de segurança ou suas políticas de acesso de endpoint. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro da APN: parceiros que podem ajudá-lo a criar soluções de computação automatizadas](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27) 
+  [AWS Auto Scaling: como funcionam os planos de escalabilidade](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [AWS Marketplace: produtos que podem ser usados com Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [Gerenciamento da capacidade de throughput de modo automático com o DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [Uso de um balanceador de carga com um grupo de Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 
+  [O que é o AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
+  [O que é o AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) 
+  [O que é o Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected) 
+  [O que é o Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
+  [O que é o Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
+  [O que é um Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
+  [O que é um Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
+  [Trabalhando com registros](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) 

# REL07-BP02 Obter recursos após a detecção de danos em uma workload
<a name="rel_adapt_to_changes_reactive_adapt_auto"></a>

 Escale recursos de modo reativo quando necessário, se a disponibilidade for afetada, para restaurar a disponibilidade da carga de trabalho. 

 Primeiro, você deve configurar as verificações de integridade e os critérios nessas verificações para indicar quando a disponibilidade é afetada pela falta de recursos. Notifique o pessoal apropriado para escalar manualmente o recurso ou inicie a automação para escalá-lo automaticamente. 

 A escala pode ser ajustada manualmente para a workload (por exemplo, alterando o número de instâncias do EC2 em um grupo do Auto Scaling ou modificando o throughput de uma tabela do DynamoDB por meio do Console de gerenciamento da AWS ou da AWS CLI). No entanto, a automação deve ser usada sempre que possível (consulte **Usar automação ao obter ou escalar recursos**). 

 **Resultado desejado:** as atividades de ajuste de escala (de forma automática ou manual) são iniciadas para restaurar a disponibilidade após a detecção de uma falha ou de uma degradação da experiência do cliente. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Implemente a observabilidade e o monitoramento em todos os componentes da workload para monitorar a experiência do cliente e detectar falhas. Defina os procedimentos, manuais ou automatizados, que escalam os recursos necessários. Para obter mais informações, consulte [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html). 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Definir os procedimentos, manuais ou automatizados, que escalam os recursos necessários. 
  +  Os procedimentos de ajuste de escala dependem de como os diferentes componentes da workload são projetados. 
  +  Eles também variam dependendo da tecnologia subjacente utilizada. 
    +  Os componentes que usam o AWS Auto Scaling podem utilizar planos de ajuste de escala para configurar um conjunto de instruções para escalar os recursos. Se você trabalha com o AWS CloudFormation ou adiciona tags aos recursos da AWS, poderá configurar planos de ajuste de escala para diferentes conjuntos de recursos por aplicação. O Auto Scaling fornece recomendações para estratégias de ajuste de escala personalizadas para cada recurso. Depois que o plano de ajuste de escala for criado, o Auto Scaling combinará os métodos de ajuste de escala dinâmica e preditiva para compatibilidade com a estratégia de ajuste de escala. Para obter mais detalhes, consulte [Como funcionam os planos de escalabilidade](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html). 
    +  O Amazon EC2 Auto Scaling verifica se você tem o número correto de instâncias do Amazon EC2 disponíveis para processar a carga da aplicação. Você cria coleções de instâncias do EC2, chamadas de grupos do Auto Scaling. É possível especificar o número mínimo e máximo de instâncias em cada grupo do Auto Scaling, e o Amazon EC2 Auto Scaling garantirá que o grupo nunca fique abaixo ou acima desses limites. Para obter mais detalhes, consulte [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
    +  O ajuste de escala automático do Amazon DynamoDB usa o serviço Application Auto Scaling para ajustar dinamicamente a capacidade de throughput provisionado por você, em resposta a padrões de tráfego reais. Isso permite que uma tabela ou um índice secundário global aumente a capacidade provisionada de leitura e gravação para sustentar aumentos repentinos no tráfego, sem controle de utilização. Para obter mais detalhes, consulte [Gerenciar a capacidade de throughput automaticamente com o Auto Scaling do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [ REL07-BP01 Usar a automação ao obter ou escalar recursos ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html) 

 **Documentos relacionados:** 
+  [AWS Auto Scaling: Como funcionam os planos de escalabilidade](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [Gerenciar a capacidade de throughput automaticamente com o Auto Scaling do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 

# REL07-BP03 Obter recursos após a detecção de que mais recursos são necessários para uma workload
<a name="rel_adapt_to_changes_proactive_adapt_auto"></a>

 Escale os recursos proativamente para atender à demanda e evitar impacto na disponibilidade. 

 Muitos serviços da AWS são escalados automaticamente para atender à demanda. Se estiver usando instâncias do Amazon EC2 ou clusters do Amazon ECS, você poderá configurar a escalabilidade automática deles para que ocorra com base nas métricas de uso que correspondam à demanda da workload. Para o Amazon EC2, a utilização média da CPU, a contagem de solicitações do load balancer ou a largura de banda da rede podem ser usadas para expandir (ou reduzir) instâncias do EC2. Para o Amazon ECS, a utilização média da CPU, a contagem de solicitações do balanceador de carga e a utilização da memória podem ser usadas para aumentar (ou reduzir) a escala horizontalmente de tarefas do ECS. Ao usar o Target Auto Scaling na AWS, o Autoscaler atua como um termostato doméstico, adicionando ou removendo recursos para manter o valor pretendido (por exemplo, 70% de utilização da CPU) que você especificar. 

 O AWS Auto Scaling também pode fazer o [Auto Scaling preditivo](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/), que usa machine learning para analisar a carga de trabalho histórica de cada recurso e prevê regularmente a carga futura para os próximos dois dias. 

 A Lei de Little ajuda a calcular quantas instâncias de computação (instâncias do EC2, funções simultâneas do Lambda etc.) são necessárias. 

 *B* = *λW* 

 L = número de instâncias (ou simultaneidade média no sistema) 

 λ = taxa média na qual as solicitações chegam (requisição por segundo) 

 W = tempo médio que cada solicitação gasta no sistema (s) 

 Por exemplo, a 100 rps, se cada solicitação demorar 0,5 segundos para ser processada, você precisará de 50 instâncias para acompanhar a demanda. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Obtenha recursos após a detecção de que mais recursos são necessários para uma workload. Escale os recursos proativamente para atender à demanda e evitar impacto na disponibilidade. 
  +  Calcule quantos recursos de computação serão necessários (simultaneidade de computação) para processar uma determinada taxa de solicitações. 
    +  [Histórias sobre a Lei de Little](https://brooker.co.za/blog/2018/06/20/littles-law.html) 
  +  Quando você tiver um padrão histórico de uso, configure a escalabilidade programada para a escalabilidade automática do Amazon EC2. 
    +  [Escalabilidade programada para o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
  +  Use a escalabilidade preditiva da AWS. 
    +  [Escalabilidade preditiva para o EC2 com Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Auto Scaling: como funcionam os planos de escalabilidade](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [AWS Marketplace: produtos que podem ser usados com Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [Gerenciamento da capacidade de throughput de modo automático com o DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [Escalabilidade preditiva para o EC2 com Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 
+  [Escalabilidade programada para o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
+  [Histórias sobre a Lei de Little](https://brooker.co.za/blog/2018/06/20/littles-law.html) 
+  [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 

# REL07-BP04 Fazer o teste de carga da sua workload
<a name="rel_adapt_to_changes_load_tested_adapt"></a>

 Adote uma metodologia de teste de carga para avaliar se a ação de escalabilidade atende aos requisitos da carga de trabalho. 

 É importante realizar testes de carga sustentada. Os testes de carga devem descobrir o ponto de interrupção e testar a performance da workload. A AWS facilita a configuração de ambientes de teste temporários que modelam a escala de sua workload 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 no local. 

 Os testes de carga em produção também devem ser considerados como parte dos dias de jogos em que o sistema de produção é destacado, durante horas de menor utilização do cliente, com todo o pessoal disponível para interpretar os resultados e resolver os problemas que surgirem. 

 **Antipadrões comuns:** 
+  Executar testes de carga em implantações que não têm a mesma configuração da sua produção. 
+  Executar testes de carga apenas em componentes individuais da carga de trabalho, e não nela toda. 
+  Executar testes de carga com um subconjunto de solicitações, e não com um conjunto representativo de solicitações reais. 
+  Executar testes de carga para um pequeno fator de segurança acima da carga esperada. 

 **Benefícios do estabelecimento dessa prática recomendada:** Você sabe quais componentes em sua arquitetura falham sob carga e pode identificar as métricas que devem ser observadas para indicar que você está se aproximando dessa carga a tempo de resolver o problema, evitando o impacto dessa falha. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Realize testes de carga para identificar qual aspecto da workload indica que é necessário adicionar ou remover capacidade. Os testes de carga devem ter tráfego representativo semelhante ao que você recebe na produção. Aumente a carga enquanto observa as métricas que você preparou para determinar aquelas que indicam quando é necessário adicionar ou remover recursos. 
  +  [Teste de carga distribuída na AWS: simular milhares de usuários conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
    +  Identifique a combinação de solicitações. Você pode ter diversas combinações de solicitações, portanto, deve examinar vários períodos ao identificar a combinação de tráfego. 
    +  Implemente um direcionador de carga. Você pode usar um código personalizado, um código aberto ou um software comercial para implementar um direcionador de carga. 
    +  Faça o teste de carga inicialmente com uma pequena capacidade. Você vê alguns efeitos imediatos ao direcionar a carga para uma capacidade menor, possivelmente tão pequena quanto uma instância ou um contêiner. 
    +  Faça o teste de carga com uma capacidade maior. Os efeitos serão diferentes em uma carga distribuída, portanto, você deve testar o mais próximo possível de um ambiente de produto. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Teste de carga distribuída na AWS: simular milhares de usuários conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 

# CONFIABILIDADE 8. Como implementar uma alteração?
<a name="rel-08"></a>

As alterações controladas são necessárias para implantar novas funcionalidades e garantir que as workloads e o ambiente operacional executem softwares conhecidos e possam ser corrigidos ou substituídos de maneira previsível. Se essas alterações forem descontroladas, será difícil prever o efeito ou resolver problemas decorrentes delas. 

**Topics**
+ [REL08-BP01 Usar runbooks para atividades padrão, como implantação](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 Integrar testes funcionais como parte da sua implantação](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 Integrar testes de resiliência como parte da sua implantação](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 Implantar usando infraestrutura imutável](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 Implantar alterações com automação](rel_tracking_change_management_automated_changemgmt.md)

# REL08-BP01 Usar runbooks para atividades padrão, como implantação
<a name="rel_tracking_change_management_planned_changemgmt"></a>

 Os runbooks são os procedimentos predefinidos para alcançar um resultado específico. Use-os para executar atividades padrão, sejam elas feitas manualmente ou automaticamente. Os exemplos incluem a implantação de uma workload, a aplicação de patches a ela ou a realização de modificações de DNS. 

 Por exemplo, coloque processos em vigor para [garantir a segurança de reversão durante implantações](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). Garantir que você possa reverter uma implantação sem qualquer interrupção para seus clientes é essencial para tornar um serviço confiável. 

 Para procedimentos de runbooks, comece com um processo manual efetivo válido, implemente-o em código e acione-o para ser executado automaticamente quando adequado. 

 Mesmo para cargas de trabalho sofisticadas altamente automatizadas, os runbooks ainda são úteis para [organizar dias de jogos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) ou atender a requisitos rigorosos de relatórios e auditoria. 

 Observe que playbooks são usados em resposta a incidentes específicos, e runbooks são usados para alcançar resultados específicos. Muitas vezes, os runbooks são para atividades de rotina, enquanto os playbooks são usados para responder a eventos que não são rotineiras. 

 **Antipadrões comuns:** 
+  Executar alterações não planejadas na configuração em produção. 
+  Ignorar as etapas do seu plano para agilizar a implantação, resultando em falha na implantação. 
+  Fazer alterações sem testar a inversão delas. 

 **Benefícios do estabelecimento desta prática recomendada:** O planejamento eficaz da alteração aumenta sua capacidade de executá-la com êxito, porque você está ciente de todos os sistemas afetados. A validação da alteração em ambientes de teste aumenta sua confiança. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Documente os procedimentos em runbooks para permitir respostas consistentes e rápidas a eventos bem conhecidos. 
  +  [AWS Well-Architected Framework: conceitos: runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html) 
+  Use o princípio de infraestrutura como código para definir sua infraestrutura. Ao usar o AWS CloudFormation (ou um terceiro confiável) para definir a infraestrutura, você poderá usar o software de controle de versão para controlar as versões e acompanhar as alterações. 
  +  Use o AWS CloudFormation (ou um provedor confiável de terceiros) para definir sua infraestrutura. 
    +  [O que é o AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
  +  Use bons princípios de design de software para criar modelos exclusivos e desacoplados. 
    +  Determine as permissões, os modelos e as partes responsáveis pela implementação. 
      + [ Controle de acesso com o AWS Identity and Access Management](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
    +  Use o controle de origem, como o AWS CodeCommit ou uma ferramenta confiável de terceiros, para controle de versão. 
      +  [O que é o AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro da APN: parceiros que podem ajudá-lo a criar soluções de implantação automatizada](https://aws.amazon.com/partners/find/results/?keyword=devops) 
+  [AWS Marketplace: produtos que podem ser usados para automatizar suas implantações](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) 
+  [AWS Well-Architected Framework: conceitos: runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html) 
+  [O que é o AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
+  [O que é o AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

   **Exemplos relacionados:** 
+  [Automatização de operações com playbooks e runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

# REL08-BP02 Integrar testes funcionais como parte da sua implantação
<a name="rel_tracking_change_management_functional_testing"></a>

 Os testes funcionais são executados como parte da implantação automatizada. Se os critérios de êxito não forem atendidos, o pipeline será interrompido ou revertido. 

 Esses testes são executados em um ambiente de pré-produção, que é preparado antes da produção no pipeline. Idealmente, isso é feito como parte de um pipeline de implantação. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Integre testes funcionais como parte da sua implantação. Os testes funcionais são executados como parte da implantação automatizada. Se os critérios de êxito não forem atendidos, o pipeline será interrompido ou revertido. 
  +  Invoque o AWS CodeBuild durante a “ação de teste” dos pipelines de lançamento de software baseados no AWS CodePipeline. Esse recurso permite que você execute facilmente uma variedade de testes no código, como testes de unidade, análises de código estático e testes de integração. 
    +  [O AWS CodePipeline adiciona compatibilidade para testes de unidade e de integração personalizada com o AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) 
  +  Use as soluções do AWS Marketplace para executar testes automatizados como parte do pipeline de entrega de software. 
    +  [Automação de teste de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [O AWS CodePipeline adiciona compatibilidade para testes de unidade e de integração personalizada com o AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) 
+  [Automação de teste de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 
+  [O que é o AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 

# REL08-BP03 Integrar testes de resiliência como parte da sua implantação
<a name="rel_tracking_change_management_resiliency_testing"></a>

 Os testes de resiliência (usando os [princípios da engenharia do caos](https://principlesofchaos.org/)) são executados como parte do pipeline de implantação automatizado em um ambiente de pré-produção. 

 Esses testes são preparados e executados no pipeline em um ambiente de pré-produção. Eles também devem ser executados em produção como parte de [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays). 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Integre testes de resiliência como parte da sua implantação. Use a engenharia do caos, a disciplina de experimentar em uma workload, para gerar confiança na capacidade da workload de resistir a condições conturbadas na produção. 
  +  Os testes de resiliência injetam falhas ou degradação de recursos para avaliar se a workload responde com a resiliência projetada. 
    +  [Laboratório do Well-Architected: nível 300: testes de resiliência do EC2 RDS e do S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html) 
  +  Esses testes podem ser executados regularmente em ambientes de pré-produção nos pipelines de implantação automatizados. 
  +  Eles também devem ser executados em produção, como parte dos dias de jogo programados. 
  +  Ao adotar os princípios da engenharia do caos, proponha hipóteses de como a carga de trabalho será executada sob várias condições adversas e, em seguida, teste essas hipóteses por meio dos testes de resiliência. 
    +  [Princípios da engenharia do caos](https://principlesofchaos.org/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Princípios da engenharia do caos](https://principlesofchaos.org/) 
+  [O que é o AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 

 **Exemplos relacionados:** 
+  [Laboratório do Well-Architected: nível 300: testes de resiliência do EC2 RDS e do S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html) 

# REL08-BP04 Implantar usando infraestrutura imutável
<a name="rel_tracking_change_management_immutable_infrastructure"></a>

 A infraestrutura imutável é um modelo que não requer atualizações, patches de segurança ou que alterações na configuração ocorram no local nas workloads de produção. Quando uma alteração é necessária, a arquitetura é criada em uma nova infraestrutura e implantada na produção. 

 Siga uma estratégia de implantação de infraestrutura imutável para aumentar a confiabilidade, a consistência e a reprodutibilidade nas implantações de workload. 

 **Resultado desejado:** com a infraestrutura imutável, nenhuma [modificação no local](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/in-place-deployments.html) é permitida para executar recursos de infraestrutura em uma workload. Em vez disso, quando uma alteração é necessária, um novo conjunto de recursos atualizados da infraestrutura que contém todas as alterações necessárias é implantado paralelamente aos recursos existentes. Essa implantação é validada automaticamente e, se bem-sucedida, o tráfego é gradualmente transferido para o novo conjunto de recursos. 

 Essa estratégia de implantação aplica-se a atualizações de software, patches de segurança, alterações na infraestrutura, atualizações de configuração e atualizações de aplicações, entre outros. 

 **Antipadrões comuns:** 
+  Implementação de mudanças no local em recursos da infraestrutura em execução. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  **Maior consistência entre os ambientes:** como não há diferenças nos recursos de infraestrutura entre os ambientes, a consistência aumenta e os testes são simplificados. 
+  **Redução dos desvios da configuração:** ao substituir os recursos da infraestrutura por uma configuração conhecida e controlada por versão, a infraestrutura é definida para um estado conhecido, testado e confiável, o que evita desvios de configuração. 
+  **Implantações atômicas confiáveis:** as implantações são concluídas com sucesso ou, do contrário, nada muda, aumentando a consistência e a confiabilidade no processo de implantação. 
+  **Implantações simplificadas:** as implantações são simplificadas porque não precisam oferecer suporte a atualizações. As atualizações são apenas novas implantações. 
+  **Implantações mais seguras com processos de reversão e recuperação rápidos:** as implantações são mais seguras porque a versão de trabalho anterior não é alterada. Você pode reverter para ele se forem detectados erros. 
+  **Procedimento de segurança aprimorado:** quando não se permitem alterações na infraestrutura, os mecanismos de acesso remoto (como o SSH) podem ser desativados. Isso reduz o vetor de ataque, melhorando o procedimento de segurança da organização. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 **Automação** 

 Ao definir uma estratégia de implantação de infraestrutura imutável, é recomendável usar a [automação](https://aws.amazon.com/iam/) o máximo possível para aumentar a reprodutibilidade e minimizar a possibilidade de erro humano. Para obter mais detalhes, consulte [REL08-BP05 Implantar alterações com automação](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html) e [Automating safe, hands-off deployments](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/). 

 Com a [infraestrutura como código (IaC)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html), as etapas de provisionamento, orquestração e implantação da infraestrutura são definidas de forma programática, descritiva e declarativa e armazenadas em um sistema de controle de origem. O uso da infraestrutura como código simplifica a automatização da implantação da infraestrutura e ajuda a obter a imutabilidade da infraestrutura. 

 **Padrões de implantação** 

 Quando uma mudança na workload é necessária, a estratégia de implantação da infraestrutura imutável exige que um novo conjunto de recursos da infraestrutura seja implantado, incluindo todas as alterações necessárias. É importante que esse novo conjunto de recursos siga um padrão de implantação que minimize o impacto sobre o usuário. Há duas estratégias principais para essa implantação: 

 [https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html): prática de direcionar um pequeno número de clientes para a nova versão, geralmente em execução em uma única instância de serviço (o canário). Em seguida, você examina profundamente todas as alterações de comportamento ou erros gerados. Você poderá remover o tráfego da implantação canário se encontrar problemas críticos e enviar os usuários de volta para a versão anterior. Se a implantação for bem-sucedida, será possível continuar a implantação a uma velocidade desejada e monitorar as alterações em busca de erros até a implantação estar concluída. O AWS CodeDeploy pode ser configurado com uma [configuração de implantação](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) que permitirá uma implantação canário. 

 [https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html): é semelhante à implantação canário, exceto que uma frota completa da aplicação é implantada em paralelo. Você alterna as implantações entre as duas pilhas (azul e verde). Novamente, é possível enviar o tráfego para a nova versão e voltar para a versão antiga se houver problemas na implantação. Normalmente, todo o tráfego é alternado de uma vez. No entanto, também é possível usar frações do tráfego para cada versão para aumentar a adoção da nova versão usando os recursos de roteamento de DNS ponderado do Amazon Route 53. O AWS CodeDeploy e o [AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2020-05-18-ts-deploy.html) podem ser definidos com uma configuração de implantação que permitirá uma implantação azul/verde. 

![\[Diagram showing blue/green deployment with AWS Elastic Beanstalk and Amazon Route 53\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/blue-green-deployment.png)


 **Detecção de desvios** 

 Define-se *desvio* como qualquer alteração que faça com que um recurso da infraestrutura tenha um estado ou uma configuração diferente do esperado. Alterações não gerenciadas da configuração, sejam de que tipo for, são contrárias ao conceito de infraestrutura imutável e devem ser detectadas e corrigidas para que a implementação da infraestrutura imutável seja bem-sucedida. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Proibir a modificação no local dos recursos de infraestrutura em execução. 
  +  É possível usar o [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) para especificar quem ou o que pode acessar serviços e recursos na AWS, gerenciar as permissões refinadas centralmente e analisar o acesso para refinar as permissões em toda a AWS. 
+  Automatize a implantação dos recursos da infraestrutura para aumentar a reprodutibilidade e minimizar a possibilidade de erro humano. 
  +  Conforme descrito no whitepaper [Introdução ao DevOps na AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html), a automação é uma referência dos serviços da AWS e é compatível com todos os serviços, recursos e ofertas. 
  +  *[Pré-fabricar](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/prebaking-vs.-bootstrapping-amis.html)* a imagem de máquina da Amazon (AMI) pode acelerar o tempo para iniciá-la. O [EC2 Image Builder](https://aws.amazon.com/image-builder/)é um serviço da AWS totalmente gerenciado que ajuda você a automatizar a criação, a manutenção, a validação, o compartilhamento e a implantação de AMIs personalizadas, seguras e atualizadas para Linux ou Windows. 
  +  Alguns dos serviços compatíveis com automação são: 
    +  O [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/)é um serviço para implantar e escalar rapidamente aplicações web desenvolvidas com Java, .NET, PHP, Node.js, Python, Ruby, Go e Docker em servidores conhecidos, como Apache, NGINX, Passenger e IIS. 
    +  O [AWS Proton](https://aws.amazon.com/proton/) ajuda as equipes da plataforma a se conectarem e coordenarem todas as diferentes ferramentas de que as equipes de desenvolvimento precisam para provisionamento de infraestrutura, implantações de código, monitoramento e atualizações. O AWS Proton permite o provisionamento de infraestrutura como código automatizada e a implantação de aplicações sem servidor e baseadas em contêineres. 
  +  A utilização da infraestrutura como código facilita a automatização da implantação da infraestrutura e ajuda a obter a imutabilidade da infraestrutura. A AWS fornece serviços que permitem a criação, a implantação e a manutenção da infraestrutura de forma programática, descritiva e declarativa. 
    +  O [AWS CloudFormation](https://aws.amazon.com/cloudformation/) ajuda os desenvolvedores a criar recursos da AWS de forma ordenada e previsível. Os recursos são escritos em arquivos de texto usando o formato JSON ou YAML. Os modelos exigem sintaxe e estrutura específicas que dependem dos tipos de recurso que estão sendo criados e gerenciados. Você cria os recursos em JSON ou YAML com qualquer editor de código, como o AWS Cloud9, e os insere em um sistema de controle de versão, e o CloudFormation cria os serviços especificados de maneira segura e repetível. 
    +  O [AWS Serverless Application Model (AWS SAM)](https://aws.amazon.com/serverless/sam/) é uma estrutura de código aberto que você pode usar para criar aplicações sem servidor na AWS. O AWS SAM integra-se a outros serviços da AWS e é uma extensão do CloudFormation. 
    +  O [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) é um framework de desenvolvimento de software de código aberto para modelar e provisionar recursos da aplicação em nuvem usando linguagens de programação conhecidas. É possível usar o AWS CDK para modelar a infraestrutura de aplicações usando TypeScript, Python, Java e .NET. O AWS CDK usa o CloudFormation em segundo plano para provisionar recursos de forma segura e repetível. 
    +  O [AWS API Cloud Control](https://aws.amazon.com/cloudcontrolapi/) apresenta um conjunto comum de APIs de criação, leitura, atualização, exclusão e lista (CRUDL) para ajudar os desenvolvedores a gerenciar a infraestrutura em nuvem de forma fácil e consistente. As APIs comuns do Cloud Control API permitem que os desenvolvedores gerenciem de maneira uniforme o ciclo de vida de serviços da AWS e de terceiros. 
+  Implemente padrões de implantação que minimizem o impacto no usuário. 
  +  Implantações canário: 
    + [ Configurar uma implantação de versão canary do API Gateway ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
    + [ Create a pipeline with canary deployments for Amazon ECS using AWS App Mesh](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/)
  +  Implantações azul/verde: o whitepaper [Blue/Green Deployments on AWS](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html) descreve [exemplos de técnicas](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/implementation-techniques.html) para implementar estratégias de implantação azul/verde. 
+  Detecte variações da configuração ou do estado. Para obter mais detalhes, consulte[Detectar alterações de configuração não gerenciadas em pilhas e recursos](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [ REL08-BP05 Implantar alterações com automação ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html)

 **Documentos relacionados:** 
+ [Automatizar uma implantação prática e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [ Leveraging AWS CloudFormation to create an immutable infrastructure at Nubank ](https://aws.amazon.com/blogs/mt/leveraging-immutable-infrastructure-nubank/)
+ [Infraestrutura como código](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+ [ Implementing an alarm to automatically detect drift in AWS CloudFormation stacks ](https://docs.aws.amazon.com/blogs/mt/implementing-an-alarm-to-automatically-detect-drift-in-aws-cloudformation-stacks/)

 **Vídeos relacionados:** 
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability ](https://www.youtube.com/watch?v=jUSYnRztttY)

# REL08-BP05 Implantar alterações com automação
<a name="rel_tracking_change_management_automated_changemgmt"></a>

 As implantações e a aplicação de patches são automatizadas para eliminar o impacto negativo. 

 As alterações nos sistemas de produção são uma das maiores áreas de risco para muitas organizações. Consideramos as implantações um problema de primeira classe a ser resolvido junto com os problemas de negócio que o software aborda. Atualmente, isso significa usar a automação nas operações sempre que for viável, incluindo testar e implantar alterações, adicionar ou remover capacidade e migrar dados. O AWS CodePipeline permite gerenciar as etapas necessárias para liberar a sua carga de trabalho. Isso inclui um estado de implantação usando o AWS CodeDeploy para automatizar a implantação do código do aplicativo em instâncias do Amazon EC2, instâncias on-premises, funções do Lambda sem servidor ou serviços do Amazon ECS. 

**Recomendação**  
 Embora a sabedoria convencional sugira que você mantenha humanos no ciclo para os procedimentos operacionais mais difíceis, sugerimos automatizar esses procedimentos exatamente por isso. 

 **Antipadrões comuns:** 
+  Executar as alterações manualmente. 
+  Ignorar as etapas da sua automação por meio de fluxos de trabalho de emergência. 
+  Não seguir seus planos. 

 **Benefícios do estabelecimento desta prática recomendada:** Ao usar a automação para implantar todas as alterações, você elimina as chances de introduzir erros humanos e permite que sejam feitos testes antes de alterar a produção para garantir que seus planos sejam conduzidos. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Automatize seu pipeline de implantação. Os pipelines de implantação permitem invocar testes automatizados e detecção de anomalias. Além disso, eles interrompem o pipeline em uma determinada etapa antes da implantação em produção ou revertem automaticamente uma alteração. 
  +  [A Amazon Builders’ Library: garanta a segurança da reversão durante implantações](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) 
  +  [A Amazon Builders’ Library: acelere a entrega contínua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/) 
    +  Use o AWS CodePipeline (ou um produto de terceiros confiável) para definir e executar seus pipelines. 
      +  Configure o pipeline para ser iniciado quando uma alteração for confirmada no repositório do seu código. 
        +  [O que é o AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 
      +  Use o Amazon Simple Notification Service (Amazon SNS) e o Amazon Simple Email Service (Amazon SES) para enviar notificações sobre problemas no pipeline ou integrar-se com uma ferramenta de bate-papo da equipe, como o Amazon Chime. 
        +  [O que é o Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 
        +  [O que é o Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) 
        +  [O que é o Amazon Chime?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html) 
        +  [Automatize mensagens de chat com webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro da APN: parceiros que podem ajudá-lo a criar soluções de implantação automatizada](https://aws.amazon.com/partners/find/results/?keyword=devops) 
+  [AWS Marketplace: produtos que podem ser usados para automatizar suas implantações](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) 
+  [Automatize mensagens de chat com webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html) 
+  [A Amazon Builders’ Library: garanta a segurança da reversão durante implantações](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) 
+  [A Amazon Builders’ Library: acelere a entrega contínua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/) 
+  [O que é o AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 
+  [O que é o CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 
+  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
+  [O que é o Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) 
+  [O que é o Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 

 **Vídeos relacionados:** 
+  [Conferência da AWS 2019: CI/CD na AWS](https://youtu.be/tQcF6SqWCoY) 

# Gerenciamento de falhas
<a name="a-failure-management"></a>

**Topics**
+ [CONFIABILIDADE 9. Como fazer backup dos dados?](rel-09.md)
+ [CONFIABILIDADE 10. Como usar o isolamento de falhas para proteger sua workload?](rel-10.md)
+ [CONFIABILIDADE 11. Como projetar a workload para resistir a falhas de componentes?](rel-11.md)
+ [CONFIABILIDADE 12. Como testar a confiabilidade?](rel-12.md)
+ [CONFIABILIDADE 13. Como planejar a recuperação de desastres (DR)?](rel-13.md)

# CONFIABILIDADE 9. Como fazer backup dos dados?
<a name="rel-09"></a>

Faça backup de dados, aplicativos e configurações para atender aos seus requisitos de Recovery Time Objective (RTO – Objetivo do tempo de recuperação) e de Recovery Point Objective (RPO – Objetivo do ponto de recuperação).

**Topics**
+ [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 Proteger e criptografar backups](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Realizar backup de dados automaticamente](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 Realizar a recuperação periódica dos dados para verificar a integridade e os processos de backup](rel_backing_up_data_periodic_recovery_testing_data.md)

# REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes
<a name="rel_backing_up_data_identified_backups_data"></a>

Compreenda e use os recursos de backup dos serviços e recursos de dados usados pela workload. A maioria dos serviços oferece recursos para fazer backup dos dados da workload. 

 **Resultado desejado:** as fontes de dados foram identificadas e classificadas com base na criticidade. Depois, estabeleça uma estratégia de recuperação de dados com base no RPO. A estratégia envolve fazer backup dessas fontes de dados ou poder reproduzir dados de outras fontes. Em caso de perda de dados, a estratégia implementada permite a recuperação ou reprodução de dados dentro do RPO e RTO definidos. 

 **Fase de maturidade da nuvem:** básica 

 **Antipadrões comuns:** 
+  Não estar ciente de todas as fontes de dados para a workload e sua criticidade. 
+  Não fazer backups de fontes de dados essenciais. 
+  Fazer backups apenas de algumas fontes de dados sem usar a criticidade como critério. 
+  Não ter um RPO definido ou a frequência de backup não atender ao RPO. 
+  Não avaliar a necessidade de um backup ou se os dados podem ser reproduzidos de outras fontes. 

 **Benefícios do estabelecimento dessa prática recomendada:** identificar os locais onde os backups são necessários e implementar um mecanismo para criar backups ou poder reproduzir os dados de uma fonte externa melhora a capacidade de restaurar e recuperar dados durante uma interrupção. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Todos os armazenamentos de dados da AWS oferecem recursos de backup. Serviços como o Amazon RDS e o Amazon DynamoDB oferecem suporte adicional ao backup automatizado que permite a recuperação a um ponto anterior no tempo (PITR), permitindo restaurar um backup a qualquer momento até cinco minutos ou menos, antes da hora atual. Muitos serviços da AWS permitem copiar backups para outra Região da AWS. O AWS Backup é uma ferramenta que permite centralizar e automatizar a proteção de dados nos serviços da AWS. O [Recuperação de desastres do AWS Elastic](https://aws.amazon.com/disaster-recovery/) permite copiar workloads de servidor completas e manter uma proteção de dados contínua de um ambiente on-premises, entre zonas de disponibilidade ou entre regiões, com um objetivo de ponto de recuperação (RPO) medido em segundos. 

 O Amazon S3 pode ser usado como um destino de backup para fontes de dados autogerenciadas e gerenciadas pela AWS. Os serviços da AWS, como o Amazon EBS, o Amazon RDS e o Amazon DynamoDB, têm recursos integrados para criar backups. É possível também usar um software de backup de terceiros. 

 E possível fazer backup de dados on-premises na Nuvem AWS usando o [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) ou o [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). Os buckets do Amazon S3 podem ser usados para armazenar esses dados na AWS. O Amazon S3 oferece vários níveis de armazenamento, como [Amazon Glacier ou Amazon Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) para reduzir os custos do armazenamento de dados. 

 Você pode atender às necessidades de recuperação de dados reproduzindo os dados de outras fontes. Por exemplo, os [nós de réplica do Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) ou as [réplicas de leitura do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) poderiam ser usadas para reproduzir dados caso os primários sejam perdidos. Em casos em que fontes como essa podem ser usadas para atender ao [objetivo de ponto de recuperação (RPO) e objetivo de tempo de recuperação (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html), pode ser que você não precise de um backup. Outro exemplo, se estiver trabalhando com o Amazon EMR, pode não ser necessário fazer backup do armazenamento de dados HDFS, contanto que você possa reproduzir os dados no Amazon EMR [ pelo Amazon S3](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/). 

 Ao selecionar uma estratégia de backup, considere o tempo necessário para recuperar os dados. Ele depende do tipo de backup (no caso de uma estratégia de backup) ou da complexidade do mecanismo de reprodução de dados. O tempo deve estar dentro do RTO para a workload. 

 **Etapas da implementação** 

1.  **Identifique todas as fontes de dados para a workload**. Os dados podem ser armazenados em vários recursos, como [bancos de dados](https://aws.amazon.com/products/databases/), [volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [sistemas de arquivos](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [sistemas de registro](https://docs.aws.amazon.com/Amazon/latest/logs/WhatIsLogs.html) e [armazenamento de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Consulte a seção **Recursos** para encontrar **Documentos relacionados** sobre diferentes serviços da AWS onde os dados são armazenados e o recurso de backup que esses serviços fornecem. 

1.  **Classifique as fontes de dados com base na criticidade**. Diferentes conjuntos de dados terão diferentes níveis de criticidade para uma workload e, portanto, diferentes requisitos de resiliência. Por exemplo, alguns dados podem ser críticos e exigir um RPO próximo de zero, enquanto outros dados podem ser menos críticos e tolerar um RPO mais alto e a perda de alguns dados. Da mesma forma, diferentes conjuntos de dados também podem ter diferentes requisitos de RTO. 

1.  **Use a AWS ou serviços de terceiros para criar backups dos dados**. O [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) é um serviço gerenciado que permite criar backups de várias fontes de dados na AWS. O [Recuperação de desastres do AWS Elastic](https://aws.amazon.com/disaster-recovery/) lida com a replicação de dados automáticos de subsegundos em uma Região da AWS. A maioria dos serviços da AWS também possui recursos nativos para criar backups. O AWS Marketplace tem muitas soluções que também fornecem esses recursos. Consulte os **Recursos** listados abaixo para obter informações sobre como criar backups de dados de vários serviços da AWS. 

1.  **Para dados sem backup, estabeleça um mecanismo de reprodução de dados**. Você pode optar por não fazer backup dos dados que podem ser reproduzidos de outras fontes por vários motivos. Às vezes, pode ser mais barato reproduzir dados de fontes se necessário, em vez de criar um backup, pois pode haver um custo associado ao armazenamento de backups. Outro exemplo é quando a restauração de um backup demora mais do que a reprodução dos dados das fontes, resultando em uma violação no RTO. Nestas situações, considere concessões e estabeleça um processo bem definido de como os dados podem ser reproduzidos dessas fontes quando a recuperação de dados for necessária. Por exemplo, se você carregou dados do Amazon S3 para um data warehouse (como o Amazon Redshift) ou para um cluster MapReduce (como o Amazon EMR) para analisá-los, esse é um exemplo de dados que podem ser reproduzidos de outras fontes. Desde que os resultados dessas análises sejam armazenados em algum lugar ou reproduzíveis, você não sofreria uma perda de dados devido a uma falha no data warehouse ou no cluster do MapReduce. Outros exemplos que podem ser reproduzidos de origens incluem caches (como o Amazon ElastiCache) ou réplicas de leitura do RDS. 

1.  **Estabeleça uma frequência para fazer backup de dados**. A criação de backups de fontes de dados é um processo periódico, e a frequência deve depender do RPO. 

 **Nível de esforço do plano de implementação:** moderado 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 

[REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md) 

[REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md) 

 **Documentos relacionados:** 
+  [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 
+  [What is AWS DataSync?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) (O que é o AWS Data Sync?) 
+  [What is Volume Gateway?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) (O que é o Gateway de Volumes?) 
+  [Parceiro do APN: parceiros que podem ajudar com o backup](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [AWS Marketplace: products that can be used for backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) (AWS Marketplace: produtos que podem ser usados para backup) 
+  [Snapshots do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html) 
+  [Backing Up Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html) (Fazer backup do Amazon EFS) 
+  [Backing up Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html) (Fazer backup do Amazon FSx para Windows File Server) 
+  [Backup e restauração para o ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html) 
+  [Creating a DB Cluster Snapshot in Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html) (Criar um snapshot do cluster de banco de dados no Neptune) 
+  [Criar um snapshot do banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) 
+  [Creating an EventBridge Rule That Triggers on a Schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) (Criar uma regra do EventBridge que é acionada de acordo com uma programação) 
+  [Replicação entre regiões](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) com o Amazon S3 
+  [EFS para EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/) 
+  [Exporting Log Data to Amazon S3](https://docs.aws.amazon.com/Amazon/latest/logs/S3Export.html) (Exportação de dados de log para o Amazon S3) 
+  [Gerenciamento do ciclo de vida de objetos](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html) 
+  [Usar backup e restauração sob demanda para o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html) 
+  [Recuperação pontual para DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html) 
+  [Criação de snapshots de índices no Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html) 
+ [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)

 **Vídeos relacionados:** 
+  [AWS re:Invent 2021: Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc) (Backup, recuperação de desastres e proteção contra ransomware com a AWS) 
+  [AWS Backup Demo: Cross-Account and Cross-Region Backup](https://www.youtube.com/watch?v=dCy7ixko3tE) (Demonstração: Backup entre contas e entre regiões) 
+  [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc) 

 **Exemplos relacionados:** 
+  [Well-Architected Lab - Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) (Laboratório do Well-Architected: implementação da replicação bidirecional entre regiões (CRR) para o Amazon S3) 
+  [Laboratório do Well-Architected: teste de backup e restauração de dados](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 
+  [Well-Architected Lab - Backup and Restore with Failback for Analytics Workload](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/) (Laboratório do Well-Architected: backup e restauração com failback para workload do Analytics) 
+  [Well-Architected Lab - Disaster Recovery - Backup and Restore](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/) (Laboratório do Well-Architected: recuperação de desastres: backup e restauração) 

# REL09-BP02 Proteger e criptografar backups
<a name="rel_backing_up_data_secured_backups_data"></a>

Controle e detecte o acesso a backups usando autenticação e autorização. Use a criptografia para prevenir e detectar se a integridade dos dados de backups está comprometida.

 **Antipadrões comuns:** 
+  Ter o mesmo acesso aos backups e à automação de restauração que os dados. 
+  Não criptografar seus backups. 

 **Benefícios do estabelecimento dessa prática recomendada:** a proteção dos backups impede a violação dos dados, e a criptografia dos dados impede o acesso a eles se forem expostos por engano. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Controle e detecte o acesso a backups usando autenticação e autorização, como o AWS Identity and Access Management (IAM). Use a criptografia para prevenir e detectar se a integridade dos dados de backups está comprometida. 

 O Amazon S3 oferece suporte a vários métodos de criptografia de dados ociosos. Ao usar a criptografia do lado do servidor, o Amazon S3 aceita os objetos como dados não criptografados e, depois, criptografa-os ao armazená-los. Ao usar a criptografia do lado do cliente, a aplicação da workload é responsável por criptografar os dados antes de serem enviados ao Amazon S3. Ambos os métodos permitem que você use o AWS Key Management Service (AWS KMS) para criar e armazenar a chave de dados, ou você pode fornecer sua própria chave, pela qual você é responsável. Usando o AWS KMS, você pode definir políticas usando o IAM sobre quem pode e não pode acessar suas chaves de dados e dados descriptografados. 

 Para o Amazon RDS, se você tiver optado por criptografar seus bancos de dados, seus backups também serão criptografados. Os backups do DynamoDB sempre são criptografados. Ao usar o Recuperação de desastres do AWS Elastic, todos os dados em trânsito e em repouso são criptografados. Com o Elastic Disaster Recovery, os dados em repouso podem ser criptografados usando a chave de criptografia de volume padrão do Amazon EBS ou uma chave personalizada gerenciada pelo cliente. 

 **Etapas da implementação** 

1.  Use a criptografia em cada um dos seus armazenamentos de dados. Se os dados de origem forem criptografados, o backup também será. 
   + [Use criptografia no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html). Você pode configurar a criptografia em repouso usando o AWS Key Management Service ao criar uma instância do RDS. 
   + [Use criptografia em volumes do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html). Você pode configurar a criptografia padrão ou especificar uma chave exclusiva após a criação do volume. 
   +  Use a [criptografia do Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) necessária. O DynamoDB criptografa todos os dados em repouso. Você pode usar uma chave do AWS KMS de propriedade da AWS ou uma chave do KMS gerenciada pela AWS, especificando uma chave armazenada na sua conta. 
   + [Criptografe seus dados armazenados no Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html). Configure a criptografia ao criar seu sistema de arquivos. 
   +  Configure a criptografia nas regiões de origem e de destino. Você pode configurar a criptografia em repouso no Amazon S3 usando as chaves armazenadas no KMS, mas as chaves são específicas da região. Você pode especificar as chaves de destino ao configurar a replicação. 
   +  Escolha se deseja usar a [critptografia do Amazon EBS para o Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/volumes-drs.html#ebs-encryption) padrão ou personalizada. Essa opção criptografa os dados em repouso replicados nos discos da sub-rede da área de preparação e os discos replicados. 

1.  Implemente permissões de privilégio mínimo para acessar seus backups. Siga as práticas recomendadas para limitar o acesso aos backups, aos snapshots e às réplicas de acordo com as [práticas recomendadas de segurança](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Marketplace: products that can be used for backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) (AWS Marketplace: produtos que podem ser usados para backup) 
+  [Criptografia do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) 
+  [Amazon S3: proteção de dados usando criptografia](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) 
+  [Replicar objetos criados com criptografia do lado do servidor (SSE) usando chaves do AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html) 
+  [Criptografia em repouso do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) 
+  [Criptografar recursos do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) 
+  [Encrypting Data and Metadata in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) (Criptografia de dados e metadados no Amazon EFS) 
+  [Encryption for Backups in AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html) (Criptografia para backups na AWS) 
+  [Gerenciamento de tabelas criptografadas](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html) 
+  [Pilar Segurança: AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) 
+ [O que é o Recuperação de desastres do AWS Elastic?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

 **Exemplos relacionados:** 
+  [Well-Architected Lab - Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) (Laboratório do Well-Architected: implementação da replicação bidirecional entre regiões (CRR) para o Amazon S3) 

# REL09-BP03 Realizar backup de dados automaticamente
<a name="rel_backing_up_data_automated_backups_data"></a>

Configure os backups para serem feitos automaticamente com base em uma programação periódica informada pelo objetivo de ponto de recuperação (RPO) ou de acordo com alterações no conjunto de dados. É necessário fazer frequentemente o backup automático de conjuntos de dados críticos com requisitos de baixa perda de dados, enquanto o backup de dados menos críticos, em que alguma perda é aceitável, pode ser feito com menos frequência.

 **Resultado desejado:** um processo automatizado que cria backups de fontes de dados em uma frequência estabelecida. 

 **Antipadrões comuns:** 
+  Fazer backups manualmente. 
+  Usar recursos que têm o recurso de backup, mas não incluir o backup em sua automação. 

 **Benefícios do estabelecimento dessa prática recomendada:** a automação de backups garante que eles sejam feitos regularmente com base no RPO, e alerta você caso isso não ocorra. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 É possível usar o AWS Backup para criar backups de dados automatizados de várias fontes de dados da AWS. É possível fazer backup das instâncias do Amazon RDS quase continuamente a cada cinco minutos e dos objetos do Amazon S3 a cada quinze minutos, proporcionando recuperação a um ponto anterior no tempo (PITR) para um momento específico no histórico de backup. Para outras fontes de dados da AWS, como volumes do Amazon EBS, tabelas do Amazon DynamoDB ou sistemas de arquivos do Amazon FSx, o AWS Backup pode executar backup automatizado de hora em hora. Esses serviços também oferecem recursos de backup nativos. Os serviços da AWS que oferecem backup automatizado com recuperação a um ponto anterior no tempo incluem [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) e [Amazon Keyspaces (para Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html). Eles podem ser restaurados a um momento específico no histórico do backup. A maioria dos outros serviços de armazenamento de dados da AWS permite programar backups periódicos, até de hora em hora. 

 O Amazon RDS e o Amazon DynamoDB oferecem backup contínuo com recuperação a um ponto anterior no tempo. O versionamento do Amazon S3, quando habilitado, é automático. O [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) pode ser usado para automatizar a criação, a cópia e a exclusão de snapshots do Amazon EBS. Ele também pode automatizar a criação, a cópia, a suspensão e o cancelamento do registro de imagens de máquina da Amazon (AMIs) com base no Amazon EBS e seus snapshots subjacentes do Amazon EBS. 

 O Recuperação de desastres do AWS Elastic fornece replicação contínua no nível de bloco do ambiente de origem (on-premises ou a AWS) para a região de recuperação de destino. Os snapshots do Amazon EBS de um ponto anterior no tempo são criados automaticamente e gerenciados pelo serviço. 

 Para obter uma visão centralizada da automação e do histórico de backups, o AWS Backup oferece uma solução de backup totalmente gerenciada e baseada em políticas. Ele centraliza e automatiza o backup de dados em vários serviços da AWS, na nuvem e on-premises, usando o AWS Storage Gateway. 

 Além do versionamento, o Amazon S3 oferece replicação. Todo o bucket do S3 pode ser replicado automaticamente para outro bucket na mesma Região da AWS ou em uma diferente. 

 **Etapas da implementação** 

1.  **Identifique fontes de dados** que estão sendo copiados manualmente. Para obter mais detalhes, consulte [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md). 

1.  **Determine o RPO** da workload. Para obter mais detalhes, consulte [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md). 

1.  **Use uma solução de backup automático ou um serviço gerenciado**. O AWS Backup é um serviço totalmente gerenciado que facilita [centralizar e automatizar a proteção de dados nos serviços da AWS, na nuvem e no ambiente on-premises](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). O uso de planos no AWS Backup permite a criação de regras que definem os recursos para backup e a frequência com que esses backups devem ser criados. A frequência deve ser informada pelo RPO estabelecido na Etapa 2. Para obter orientações práticas sobre como criar backups automáticos usando o AWS Backup, consulte [Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) (Teste de backup e restauração de dados). A maioria dos serviços da AWS que armazenam dados oferecem recursos de backup nativos. Por exemplo, o RDS pode ser aproveitado para backups automatizados com recuperação a um ponto anterior no tempo (PITR). 

1.  **Para fontes de dados incompatíveis** com uma solução de backup automatizado ou serviço gerenciado, como fontes de dados ou filas de mensagens on-premises, considere usar uma solução confiável de terceiros para criar backups automatizados. Como alternativa, você pode criar automação para fazer isso usando a AWS CLI ou os SDKs. Você pode usar o AWS Lambda Functions ou o AWS Step Functions para definir a lógica envolvida na criação de um backup de dados e o Amazon EventBridge para executá-la em uma frequência baseada no RPO. 

 **Nível de esforço do plano de implementação:** baixo 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro do APN: parceiros que podem ajudar com o backup](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [AWS Marketplace: products that can be used for backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) (AWS Marketplace: produtos que podem ser usados para backup) 
+  [Creating an EventBridge Rule That Triggers on a Schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) (Criar uma regra do EventBridge que é acionada de acordo com uma programação) 
+  [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 
+ [O que é o Recuperação de desastres do AWS Elastic?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

 **Vídeos relacionados:** 
+  [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc) 

 **Exemplos relacionados:** 
+  [Laboratório do Well-Architected: teste de backup e restauração de dados](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 

# REL09-BP04 Realizar a recuperação periódica dos dados para verificar a integridade e os processos de backup
<a name="rel_backing_up_data_periodic_recovery_testing_data"></a>

Execute um teste de recuperação para confirmar se a implementação do processo de backup atende aos seus objetivos de tempo de recuperação (RTO) e de ponto de recuperação (RPO).

 **Resultado desejado:** os dados de backups são recuperados periodicamente usando mecanismos bem definidos para garantir que a recuperação seja possível dentro do objetivo de tempo de recuperação (RTO) estabelecido para a workload. Verifique se a restauração de um backup resulta em um recurso contendo os dados originais sem que estejam corrompidos ou inacessíveis e que a perda de dados esteja dentro do objetivo de ponto de recuperação (RPO). 

 **Antipadrões comuns:** 
+  Restaurar um backup, mas não consultar ou recuperar os dados para garantir que a restauração seja útil. 
+  Presumir a existência de um backup. 
+  Presumir que o backup de um sistema esteja totalmente operacional e que os dados possam ser recuperados dele. 
+  Presumir que o tempo para recuperar ou restaurar dados de um backup esteja dentro do RTO para a workload. 
+  Presumir que os dados contidos no backup estejam dentro do RPO para a workload. 
+  Restaurar ad hoc, sem usar um runbook, ou o lado de fora de um procedimento automatizado estabelecido. 

 **Benefícios do estabelecimento dessa prática recomendada:** testar a recuperação dos backups garante que os dados possam ser restaurados quando necessário, sem a preocupação de que possam estar ausentes ou corrompidos. Os testes também garantem que a restauração e a recuperação sejam possíveis de acordo com o RTO da workload e qualquer perda de dados se enquadre no RPO da workload. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Testar a capacidade de backup e de restauração aumenta a confiança na aptidão de realizar essas ações durante uma interrupção. Restaure periodicamente os backups em um novo local e execute testes para verificar a integridade dos dados. Alguns testes comuns que devem ser realizados são verificar se todos os dados estão disponíveis, não corrompidos, acessíveis e garantir que toda a perda de dados se enquadre no RPO da workload. Eles também podem ajudar a verificar se os mecanismos de recuperação são rápidos o suficiente para acomodar o RTO da workload. 

 Ao usar a AWS, você pode criar um ambiente de teste e restaurar os backups para avaliar os recursos de RTO e RPO e executar testes de conteúdo e integridade dos dados. 

 Além disso, o Amazon RDS e o Amazon DynamoDB permitem a recuperação point-in-time (PITR). Ao usar o backup contínuo, você pode restaurar o conjunto de dados para o estado em que estava em uma data e hora especificadas. 

 Se todos os dados estiverem disponíveis, não corrompidos, acessíveis e qualquer perda de dados está de acordo com o RPO da workload. Eles também podem ajudar a verificar se os mecanismos de recuperação são rápidos o suficiente para acomodar o RTO da workload. 

 O Recuperação de desastres do AWS Elastic oferece snapshots contínuos de recuperação a um ponto anterior no tempo de volumes do Amazon EBS. Como os servidores de origem são replicados, os estados de um ponto anterior no tempo são registrados ao longo do tempo com base na política configurada. O Elastic Disaster Recovery ajuda a verificar a integridade desses snapshots iniciando instâncias para fins de teste e simulação sem redirecionar o tráfego. 

 **Etapas da implementação** 

1.  **Identifique fontes de dados** das quais está sendo feito backup no momento e onde esses backups estão sendo armazenados. Para obter orientações de implementação, consulte [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md). 

1.  **Estabeleça critérios para a validação de dados** a cada fonte de dados. Diferentes tipos de dados terão propriedades distintas que podem exigir mecanismos de validação diferentes. Considere como validar esses dados antes de se sentir confiante em usá-los na produção. Algumas maneiras comuns de validar dados são o uso de dados e propriedades de backup, como tipo de dados, formato, soma de verificação, tamanho ou uma combinação deles com lógica de validação personalizada. Por exemplo, pode ser uma comparação dos valores de soma de verificação entre o recurso restaurado e a fonte de dados no momento em que o backup foi criado. 

1.  **Estabeleça o RTO e o RPO** para restaurar os dados com base na criticidade deles. Para obter orientações de implementação, consulte [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md). 

1.  **Avalie sua capacidade de recuperação**. Revise sua estratégia de backup e de restauração para entender se ela pode cumprir o RTO e o RPO e ajuste a estratégia conforme necessário. Usando o [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html), você pode executar uma avaliação da workload. Essa avaliação analisa a configuração da aplicação em relação à política de resiliência e relata se as metas de RTO e RPO podem ser cumpridas. 

1.  **Faça uma restauração de teste** com os processos atualmente estabelecidos usados ​​na produção para restauração de dados. Esses processos dependem de como foi feito o backup da fonte de dados original, do formato e do local de armazenamento do próprio backup ou se os dados são reproduzidos de outras fontes. Por exemplo, se você estiver usando um serviço gerenciado, como o [AWS Backup, isso pode ser tão simples quanto restaurar o backup em um novo recurso](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). Se você usar o Recuperação de desastres do AWS Elastic, poderá [iniciar uma simulação de recuperação](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html). 

1.  **Valide a recuperação de dados** do recurso restaurado com base nos critérios estabelecidos anteriormente para validação dos dados. Os dados restaurados e recuperados contêm o registro ou item mais recente no momento do backup? Esses dados se enquadram no RPO da workload? 

1.  **Calcule o tempo necessário** para a restauração e recuperação e compare-o com o RTO estabelecido. Esse processo se enquadra no RTO da workload? Por exemplo, compare o carimbo de data/hora em que o processo de restauração foi iniciado e que a validação da recuperação foi concluída para calcular quanto tempo esse processo leva. Todas as chamadas de API da AWS têm carimbo de data/hora e essas informações estão disponíveis no [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Embora essas informações possam fornecer detalhes sobre o início do processo de restauração, o carimbo final de data/hora da conclusão da validação deve ser registrado pela lógica de validação. Se você usar um processo automático, serviços como o [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) poderão ser usados para armazenar essas informações. Além disso, muitos serviços da AWS oferecem um histórico de eventos que fornece informações sobre a data e hora em que determinadas ações ocorreram. No AWS Backup, as ações de backup e restauração são chamadas de *trabalhos*, e esses trabalhos contêm informações de data e hora como parte dos metadados, que podem ser usados ​​para calcular o tempo necessário para restauração e recuperação. 

1.  **Informe as partes interessadas** se a validação de dados falhar ou se o tempo necessário para restauração e recuperação exceder o RTO estabelecido para a workload. Ao implementar a automação para fazer isso, [como neste laboratório](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/), serviços como o Amazon Simple Notification Service (Amazon SNS) podem ser usados para enviar notificações por push como e-mail ou SMS às partes interessadas. [Essas mensagens também podem ser publicadas em aplicações de mensagens, como o Amazon Chime, o Slack ou o Microsoft Teams](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) ou usadas para [criar tarefas como OpsItems usando o AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html). 

1.  **Automatize esse processo para ser executado periodicamente**. Por exemplo, serviços como o AWS Lambda ou uma máquina de estado no AWS Step Functions podem ser usados ​​para automatizar os processos de restauração e recuperação, e é possível usar o Amazon EventBridge ​​para acionar esse fluxo de trabalho de automação periodicamente, conforme mostrado no diagrama de arquitetura abaixo. Saiba como [Automatizar a validação da recuperação de dados com o AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Além disso, [este laboratório do Well-Architected](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) fornece uma experiência prática de como automatizar várias das etapas aqui. 

![\[Diagrama mostrando um processo de backup e restauração automatizado\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/automated-backup-restore-process.png)


 **Nível de esforço do plano de implementação:** moderado a alto, dependendo da complexidade dos critérios de validação. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Automate data recovery validation with AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/) (Automatizar validação de recuperação de dados com o AWS Backup) 
+  [Parceiro do APN: parceiros que podem ajudar com o backup](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [AWS Marketplace: products that can be used for backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) (AWS Marketplace: produtos que podem ser usados para backup) 
+  [Creating an EventBridge Rule That Triggers on a Schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) (Criar uma regra do EventBridge que é acionada de acordo com uma programação) 
+  [Usar backup e restauração sob demanda para o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html) 
+  [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 
+  [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 
+  [Recuperação de desastres do AWS Elastic](https://aws.amazon.com/disaster-recovery/) 

 **Exemplos relacionados:** 
+  [Laboratório do Well-Architected: teste de backup e restauração de dados](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 

# CONFIABILIDADE 10. Como usar o isolamento de falhas para proteger sua workload?
<a name="rel-10"></a>

Os limites isolados de falhas restringem o efeito de uma falha em uma carga de trabalho a um número controlado de componentes. A falha não afeta os componentes fora do limite. Ao usar vários limites isolados de falhas, você pode restringir o impacto sobre sua carga de trabalho.

**Topics**
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Escolher os locais apropriados para sua implantação de vários locais](rel_fault_isolation_select_location.md)
+ [REL10-BP03 Automatizar a recuperação de componentes restritos a um único local](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 Usar arquiteturas de anteparo para limitar o escopo de impacto](rel_fault_isolation_use_bulkhead.md)

# REL10-BP01 Implantar a workload em vários locais
<a name="rel_fault_isolation_multiaz_region_system"></a>

 Distribua os dados e os recursos da workload por várias zonas de disponibilidade ou por Regiões da AWS, quando necessário. A diversidade dos locais pode variar conforme a necessidade. 

 Um dos princípios fundamentais do design de serviço na AWS é evitar pontos únicos de falha em infraestrutura física subjacente. Isso nos motiva a criar software e sistemas que usam várias zonas de disponibilidade e são resilientes à falha de uma única zona. De modo similar, os sistemas são criados para serem resilientes à falha de um único nó de computação, volume de armazenamento ou instância de um banco de dados. Ao criar um sistema que dependa de componentes redundantes, é importante garantir que os componentes operem de modo independente e, no caso de Regiões da AWS, de modo autônomo. Os benefícios obtidos com cálculos teóricos de disponibilidade com componentes redundantes só serão válidos se isso for verdadeiro. 

 **Zonas de disponibilidade (AZ)** 

 As Regiões da AWS são compostas de várias zonas de disponibilidade projetadas para serem independentes umas das outras. Cada zona de disponibilidade é separada por uma grande distância física de outras zonas para evitar cenários de falha correlacionados devido a riscos ambientais, como incêndios, enchentes e tornados. Cada zona de disponibilidade tem uma infraestrutura física independente: conexões dedicadas à rede elétrica, fontes de alimentação de reserva independentes, serviços mecânicos independentes e conectividade de rede independente dentro e além da zona de disponibilidade. O design limita as falhas em qualquer um desses sistemas apenas à AZ afetada. Apesar de estarem geograficamente separadas, as zonas de disponibilidade estão localizadas na mesma área regional, permitindo uma rede de alto throughput e baixa latência. Toda a Região da AWS (em todas as zonas de disponibilidade, consistindo em vários datacenters fisicamente independentes) pode ser tratada como um único destino de implantação lógica para a workload, incluindo a capacidade de replicar dados de forma síncrona (por exemplo, entre bancos de dados). Assim, você pode usar as zonas de disponibilidade em uma configuração ativa/ativa ou ativa/em espera. 

 As zonas de disponibilidade são independentes e, portanto, a disponibilidade da workload aumenta quando ela é projetada para usar várias zonas. Alguns serviços da AWS (incluindo o plano de dados da instância do Amazon EC2) são implantados como serviços estritamente zonais, compartilhando o destino com a zona de disponibilidade em que estão. No entanto, as instâncias do Amazon EC2 nas outras AZs não serão afetadas e continuarão funcionando. Da mesma forma, se uma falha em uma zona de disponibilidade fizer com que um banco de dados do Amazon Aurora falhe, uma instância do Aurora de réplica de leitura em uma AZ não afetada poderá ser promovida automaticamente para primária. Entretanto, os serviços da AWS regionais (como o Amazon DynamoDB) usam várias zonas de disponibilidade em uma configuração ativa/ativa para atingir as metas de design de disponibilidade para aquele serviço, sem a necessidade de configurar o posicionamento da AZ. 

![\[Diagrama mostrando arquitetura multicamada implantada em três zonas de disponibilidade. Observe que o Amazon S3 e o Amazon DynamoDB são sempre multi-AZ automaticamente. O ELB também é implantado em todas as três zonas.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/multi-tier-architecture.png)


 Embora os ambientes de gerenciamento da AWS costumem permitir o gerenciamento de recursos dentro de toda a região (várias zonas de disponibilidade), determinados ambientes (incluindo o Amazon EC2 e o Amazon EBS) podem filtrar os resultados para uma única zona de disponibilidade. Quando isso é feito, a solicitação é processada apenas na zona de disponibilidade especificada, o que reduz a exposição a interrupções em outras zonas de disponibilidade. Veja um exemplo da AWS CLI que ilustra como obter informações da instância do Amazon EC2 apenas da zona de disponibilidade us-east-2c: 

```
 AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```

 *Zonas locais da AWS* 

 Zonas locais da AWS atuam de forma semelhante às zonas de disponibilidade nas suas respectivas Região da AWS, pois elas podem ser selecionadas como um local de posicionamento para recursos zonais da AWS, como sub-redes e instâncias do EC2. O que as torna especiais é que elas estão localizadas não na Região da AWS associada, mas perto de grandes centros populacionais, industriais e de TI onde não existe nenhuma Região da AWS atualmente. No entanto, elas ainda mantêm uma conexão segura e de alta largura de banda entre as workloads locais na zona local e as executadas na Região da AWS. Você deve usar as zonas locais da AWS para implantar workloads mais perto dos seus usuários para requisitos de baixa latência. 

 **Amazon Global Edge Network** 

 A Amazon Global Edge Network consiste em locais da borda em cidades ao redor do mundo. O Amazon CloudFront usa essa rede para entregar conteúdo aos usuários finais com menor latência. O AWS Global Accelerator permite criar endpoints de workload nesses locais da borda para fornecer integração à rede global da AWS próxima aos seus usuários. O Amazon API Gateway habilita endpoints de API otimizados para borda usando uma distribuição do CloudFront para facilitar o acesso do cliente por meio do local da borda mais próximo. 

 *Regiões da AWS* 

 As Regiões da AWS foram projetadas para serem autônomas. Portanto, para usar uma abordagem multirregional, você pode implantar cópias dedicadas de serviços em cada região. 

 Uma abordagem multirregional é comum para estratégias de *recuperação de desastres* atenderem aos objetivos de recuperação quando ocorrem eventos pontuais de grande escala. Perceber [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) para obter mais informações sobre essas estratégias. No entanto, aqui focaremos na *disponibilidade*, que busca entregar um objetivo de tempo de atividade médio ao longo do tempo. Para objetivos de alta disponibilidade, geralmente uma arquitetura multirregional será projetada para ser ativa/ativa, onde cada cópia de serviço (nas suas respectivas regiões) está ativa (atendimento a solicitações). 

**Recomendação**  
 Os objetivos de disponibilidade para a maioria das workloads podem ser cumpridos usando uma estratégia multi-AZ em uma única Região da AWS. Considere arquiteturas multirregionais somente quando as workloads tiverem requisitos de disponibilidade extrema ou outros objetivos de negócios que exijam uma arquitetura multirregional. 

 A AWS oferece a capacidade de operar serviços entre regiões. Por exemplo, a AWS fornece replicação contínua e assíncrona de dados usando replicação do Amazon Simple Storage Service (Amazon S3), réplicas de leitura do Amazon RDS (incluindo réplicas de leitura do Aurora) e tabelas globais do Amazon DynamoDB. Com a replicação contínua, as versões dos dados estão disponíveis para uso quase imediato em cada uma das suas regiões ativas. 

 Ao usar o AWS CloudFormation, você pode definir a infraestrutura e implantá-la de forma consistente em todas as Contas da AWS e Regiões da AWS. O AWS CloudFormation StackSets estende essa funcionalidade, permitindo que criar, atualizar ou excluir pilhas do AWS CloudFormation em várias contas e regiões com uma única operação. Para implantações de instância do Amazon EC2, uma imagem de máquina da Amazon (AMI) é usada para fornecer informações como configuração de hardware e software instalado. É possível implementar um pipeline do construtor de imagem do Amazon EC2 que cria as AMIs necessárias e as copia para as regiões ativas. Isso garante que essas *AMIs de referência (golden)* tenham o necessário para implantar e expandir a workload em cada nova região. 

 Para rotear o tráfego, o Amazon Route 53 e o AWS Global Accelerator permitem a definição de políticas que determinam os usuários que vão para cada endpoint regional ativo. Com o Global Accelerator, você define uma discagem de tráfego para controlar a porcentagem do tráfego que é direcionado para cada endpoint da aplicação. O Route 53 é compatível com a abordagem de porcentagem e com várias outras políticas disponíveis, incluindo as 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 à estrutura da rede da AWS o mais rápido possível, resultando em menores latências de solicitação. 

 Todos esses recursos operam de forma a preservar a autonomia de cada região. Há poucas exceções a essa abordagem, incluindo nossos serviços que fornecem entrega global de borda (como o Amazon CloudFront e o Amazon Route 53), juntamente com o ambiente de gerenciamento para o serviço AWS Identity and Access Management (IAM). A maioria dos serviços opera totalmente dentro de uma única região. 

 **Datacenter no local** 

 Para workloads executadas em um datacenter on-premises, arquitete uma experiência híbrida quando possível. O AWS Direct Connect fornece uma conexão de rede dedicada entre o local e a AWS, permitindo que você execute em ambos. 

 Outra opção é executar a infraestrutura e os serviços da AWS on-premises usando o AWS Outposts. O AWS Outposts é um serviço totalmente gerenciado que estende a infraestrutura da AWS, os serviços da AWS, as APIs e as ferramentas para o seu datacenter. A mesma infraestrutura de hardware usada na Nuvem AWS é instalada no seu datacenter. O AWS Outposts é então conectados à Região da AWS mais próxima. Em seguida, você pode usar AWS Outposts para oferecer suporte a cargas de trabalho com baixa latência ou requisitos de processamento de dados locais. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Use várias zonas de disponibilidade e Regiões da AWS. Distribua os dados e os recursos da workload por várias zonas de disponibilidade ou por Regiões da AWS, quando necessário. A diversidade dos locais pode variar conforme a necessidade. 
  +  Os serviços regionais são inerentemente implantados nas zonas de disponibilidade. 
    +  Isso inclui o Amazon S3, o Amazon DynamoDB e o AWS Lambda (quando não conectados a uma VPC). 
  +  Implemente suas cargas de trabalho baseadas em contêiner, instância e função em várias zonas de disponibilidade. Use datastores multizona, incluindo caches. Use os recursos do EC2 Auto Scaling, o posicionamento de tarefas do ECS, a configuração da função do AWS Lambda ao executá-lo na sua VPC e clusters do ElastiCache. 
    +  Use sub-redes que estão em zonas de disponibilidade separadas ao implantar grupos de Auto Scaling. 
      +  [Exemplo: distribuição de instâncias entre zonas de disponibilidade](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) 
      +  [Estratégias de posicionamento de tarefas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) 
      +  [Configuração de uma função do AWS Lambda para acessar recursos em uma Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html) 
      +  [Escolha de regiões e zonas de disponibilidade](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html) 
    +  Use sub-redes que estão em zonas de disponibilidade separadas ao implantar grupos de Auto Scaling. 
      +  [Exemplo: distribuição de instâncias entre zonas de disponibilidade](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) 
    +  Use os parâmetros de posicionamento de tarefas do ECS, especificando grupos de sub-rede do banco de dados. 
      +  [Estratégias de posicionamento de tarefas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) 
    +  Use sub-redes em várias zonas de disponibilidade ao configurar uma função para executar na sua VPC. 
      +  [Configuração de uma função do AWS Lambda para acessar recursos em uma Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html) 
    +  Use várias zonas de disponibilidade com os clusters do ElastiCache. 
      +  [Escolha de regiões e zonas de disponibilidade](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html) 
+  Se a workload precisar ser implantada em várias regiões, escolha uma estratégia multirregional. A maioria das necessidades de confiabilidade pode ser atendida em uma única Região da AWS usando uma estratégia de várias zonas de disponibilidade. Use uma estratégia multirregional quando necessário para atender às suas demandas empresariais. 
  +  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
    +  O backup para outra Região da AWS pode servir como mais uma camada visando garantir que os dados estejam disponíveis quando necessário. 
    +  Algumas workloads têm requisitos regulamentares que exigem o uso de uma estratégia multirregional. 
+  Avalie o AWS Outposts para a workload. Se a carga de trabalho exigir baixa latência do datacenter no local ou tiver requisitos de processamento de dados locais. Em seguida, execute a infraestrutura e os serviços da AWS on-premises usando o AWS Outposts 
  +  [O que é o AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) 
+  Determine se as zonas locais da AWS ajudam você a fornecer serviços aos usuários. Se você tiver requisitos de baixa latência, veja se as zonas locais da AWS estão próximas dos seus usuários. Se estiverem, use-as para implantar as workloads mais próximas desses usuários. 
  +  [Perguntas frequentes sobre zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Infraestrutura global da AWS](https://aws.amazon.com/about-aws/global-infrastructure) 
+  [Perguntas frequentes sobre zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/) 
+  [Estratégias de posicionamento de tarefas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) 
+  [Escolha de regiões e zonas de disponibilidade](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html) 
+  [Exemplo: distribuição de instâncias entre zonas de disponibilidade](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) 
+  [Tabelas globais: replicação em várias regiões com o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html) 
+  [Uso de bancos de dados globais do Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) 
+  [Série de blogs sobre a criação de uma aplicação multirregional com os serviços da AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) 
+  [O que é o AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
+  [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (NET339)](https://youtu.be/UObQZ3R9_4c) 

# REL10-BP02 Escolher os locais apropriados para sua implantação de vários locais
<a name="rel_fault_isolation_select_location"></a>

## Resultado desejado
<a name="desired-outcome"></a>

 Para alta disponibilidade, sempre (que possível) implante os componentes da workload em várias zonas de disponibilidade (AZs), conforme mostrado na figura 10. Para workloads com requisitos de resiliência extrema, avalie cuidadosamente as opções para uma arquitetura multirregional. 

![\[Diagrama mostrando uma implantação de banco de dados resiliente com backup para outra região da AWS\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/multi-az-architecture.png)


## Antipadrões comuns:
<a name="common-anti-patterns"></a>
+  Projetar uma arquitetura multirregional quando uma arquitetura multi-AZ seria suficiente para atender aos requisitos. 
+  Não contabilizar as dependências entre os componentes da aplicação caso os requisitos de resiliência e de vários locais forem diferentes entre esses componentes. 

## Benefícios do estabelecimento desta prática recomendada:
<a name="benefits-of-establishing-this-best-practice"></a>

 Para resiliência, você deve usar uma abordagem que construa camadas de defesa. Uma camada protege contra interrupções menores e mais comuns criando uma arquitetura altamente disponível usando várias AZs. Outra camada de defesa destina-se a proteger contra eventos raros, como desastres naturais generalizados e interrupções em nível regional. Essa segunda camada envolve arquitetar a aplicação para abranger várias Regiões da AWS. 
+  A diferença entre as disponibilidades de 99,5% e 99,99% é superior a 3,5 horas por mês. A disponibilidade esperada de uma workload só pode atingir “quatro noves” se estiver em várias AZs. 
+  Ao executar a workload em várias AZs, é possível isolar falhas de energia, refrigeração, rede e a maioria dos desastres naturais, como incêndio e inundação. 
+  A implementação de uma estratégia multirregional para a workload ajuda a protegê-la contra desastres naturais generalizados, que afetam uma grande área geográfica de um país, ou falhas técnicas de escopo regional. Esteja ciente de que a implementação de uma arquitetura multirregional pode ser complexa e, geralmente, não é necessária para a maioria das workloads. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Para um evento de desastre baseado em interrupção ou perda parcial de uma zona de disponibilidade, implementar uma workload altamente disponível em várias zonas de disponibilidade em uma única Região da AWS ajuda a atenuar os desastres naturais e técnicos. Cada Região da AWS é composta por várias zonas de disponibilidade, cada uma isolada de falhas nas outras zonas e separadas por uma distância significativa. No entanto, para um evento de desastre que inclua o risco de perder vários componentes da zona de disponibilidade, distantes umas das outras de forma significativa, deve-se implementar opções de recuperação de desastres para atenuar as falhas de escopo regional. Para workloads que exigem resiliência extrema (infraestrutura crítica, aplicações relacionados à integridade, infraestrutura do sistema financeiro etc.), pode ser necessária uma estratégia multirregional. 

## Etapas da implementação
<a name="implementation-steps"></a>

1.  Avalie a workload e determine se as necessidades de resiliência podem ser atendidas por uma abordagem multi-AZ (Região da AWS única) ou se elas requerem uma abordagem multirregional. A implementação de uma arquitetura multirregional para atender a esses requisitos introduzirá complexidade adicional, portanto, considere cuidadosamente seu caso de uso e seus requisitos. Os requisitos de resiliência quase sempre podem ser atendidos usando uma única Região da AWS. Considere os seguintes requisitos possíveis ao determinar a necessidade de usar várias regiões: 

   1.  **Recuperação de desastres (DR)**: para um evento de desastre baseado em interrupção ou perda parcial de uma zona de disponibilidade, implementar uma workload altamente disponível em várias zonas de disponibilidade em uma única Região da AWS ajuda a atenuar os desastres naturais e técnicos. Para um evento de desastre que inclua o risco de perder vários componentes da zona de disponibilidade, distantes umas das outras de forma significativa, deve-se implementar recuperação de desastres multirregional para atenuar os desastres naturais ou as falhas técnicas de escopo regional. 

   1.  **Alta disponibilidade (AD)**: é possível usar uma arquitetura multirregional (usando várias AZs em cada região) para alcançar uma disponibilidade superior a quatro noves (> 99,99%). 

   1.  **Localização de pilhas**: ao implantar uma workload para um público global, é possível implantar pilhas localizadas em diferentes Regiões da AWS para atender o público nessas regiões. A localização pode incluir idioma, moeda e tipos de dados armazenados. 

   1.  **Proximidade aos usuários:** ao implantar uma workload para um público global, é possível reduzir a latência implantando pilhas em Regiões da AWS perto de onde os usuários finais estão. 

   1.  **Residência de dados**: algumas workloads estão sujeitas a requisitos de residência de dados, em que os dados de determinados usuários devem permanecer dentro das fronteiras de um país específico. Com base na regulamentação em questão, você pode optar por implantar uma pilha inteira ou apenas os dados na Região da AWS dentro dessas fronteiras. 

1.  Veja alguns exemplos de funcionalidade multi-AZ fornecida pelos serviços da AWS: 

   1.  Para proteger workloads usando o EC2 ou o ECS, implante um Elastic Load Balancer na frente dos recursos de computação. Em seguida, o Elastic Load Balancing fornece a solução para detectar instâncias em zonas com problemas de integridade e rotear o tráfego para as íntegras. 

      1.  [Conceitos básicos do Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html) 

      1.  [Conceitos básicos do Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html) 

   1.  Em caso de instâncias do EC2 executando software comercial pronto para uso que não oferece suporte ao balanceamento de carga, é possível obter uma forma de tolerância a falhas implementando uma metodologia de recuperação de desastre multi-AZ. 

      1. [REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)

   1.  Para tarefas do Amazon ECS, implante seu serviço uniformemente em três AZs para alcançar um equilíbrio entre disponibilidade e custo. 

      1.  [Práticas recomendadas de disponibilidade do Amazon ECS \$1 Contêineres](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/) 

   1.  Para os que não são Aurora Amazon RDS, você pode escolher multi-AZ como uma opção de configuração. Em caso de falha da instância de banco de dados primário, o Amazon RDS promove automaticamente um banco de dados em espera para receber o tráfego em outra zona de disponibilidade. Também é possível criar réplicas de leitura multirregionais para melhorar a resiliência. 

      1.  [Implantações multi-AZ do Amazon RDS](https://aws.amazon.com/rds/features/multi-az/) 

      1.  [Criação de uma réplica de leitura em uma Região da AWS diferente](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html) 

1.  Veja alguns exemplos de funcionalidade multirregional fornecida pelos serviços da AWS: 

   1.  Para workloads do Amazon S3, em que a disponibilidade multi-AZ é fornecida automaticamente pelo serviço, considere os pontos de acesso multirregionais se for necessária uma implantação multirregional. 

      1.  [Pontos de acesso multirregionais no Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html) 

   1.  Para tabelas do DynamoDB, em que a disponibilidade multi-AZ é fornecida automaticamente pelo serviço, é possível converter tabelas existentes em tabelas globais para aproveitar várias regiões. 

      1.  [Conversão de tabelas de região única do Amazon DynamoDB em tabelas globais](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/) 

   1.  Se a workload for liderada pelo Application Load Balancers ou pelo Network Load Balancers, use o AWS Global Accelerator para melhorar a disponibilidade da aplicação direcionando o tráfego para várias regiões que contenham endpoints íntegros. 

      1.  [Endpoints para aceleradores padrão no AWS Global Accelerator – AWS Global Accelerator (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html) 

   1.  Para aplicações que utilizam o AWS EventBridge, considere os barramentos entre regiões para encaminhar eventos para outras regiões selecionadas. 

      1.  [Envio e recebimento de eventos do Amazon EventBridge entre Regiões da AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html) 

   1.  Para bancos de dados do Amazon Aurora, considere os bancos de dados globais do Aurora, que abrangem várias regiões da AWS. Os clusters existentes também podem ser modificados para adicionar novas regiões. 

      1.  [Conceitos básicos dos bancos de dados globais do Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html) 

   1.  Se a workload incluir chaves de criptografia do AWS Key Management Service (AWS KMS), considere se as chaves multirregionais são apropriadas para a aplicação. 

      1.  [Chaves multirregionais no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) 

   1.  Para recursos de outros serviços da AWS, consulte [Série sobre a criação de uma aplicação multirregional com os serviços da AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) 

 **Nível de esforço para o plano de implementação: **Moderado a alto 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Série sobre a criação de uma aplicação multirregional com os serviços da AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) 
+  [Arquitetura de recuperação de desastres (DR) na AWS, parte IV: multissite ativo-ativo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/) 
+  [Infraestrutura global da AWS](https://aws.amazon.com/about-aws/global-infrastructure) 
+  [Perguntas frequentes sobre zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/) 
+  [Arquitetura de recuperação de desastres (DR) na AWS, parte I: estratégias de recuperação na nuvem](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) 
+  [Recuperação de desastres é diferente na nuvem](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html) 
+  [Tabelas globais: replicação em várias regiões com o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
+  [Auth0: arquitetura multirregional de alta disponibilidade que escala a até mais de 1,5 bilhão de logins por mês com failover automático](https://www.youtube.com/watch?v=vGywoYc_sA8) 

   **Exemplos relacionados:** 
+  [Arquitetura de recuperação de desastres (DR) na AWS, parte I: estratégias de recuperação na nuvem](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) 
+  [DTCC alcança resiliência muito além do que conseguem em ambiente on-premises](https://aws.amazon.com/solutions/case-studies/DTCC/) 
+  [Expedia Group usa uma arquitetura multirregional e de várias zonas de disponibilidade com um serviço de DNS proprietário para adicionar resiliência às aplicações](https://aws.amazon.com/solutions/case-studies/expedia/) 
+  [Uber: recuperação de desastres para Kafka multirregional](https://eng.uber.com/kafka/) 
+  [Netflix: ativo-ativo para resiliência multirregional](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b) 
+  [Como criamos residência de dados para o Atlassian Cloud](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud) 
+  [Intuit TurboTax executa em duas regiões](https://www.youtube.com/watch?v=286XyWx5xdQ) 

# REL10-BP03 Automatizar a recuperação de componentes restritos a um único local
<a name="rel_fault_isolation_single_az_system"></a>

Se os componentes da workload só puderem ser executados em uma única zona de disponibilidade ou datacenter on-premises, você deverá implementar capacidade suficiente para fazer uma recompilação completa da workload em conformidade com os objetivos de recuperação definidos.

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Se a melhor prática para implantar a carga de trabalho em vários locais não for possível devido a restrições tecnológicas, você deverá implementar um caminho alternativo para a resiliência. Você deve automatizar a capacidade de recriar a infraestrutura necessária, reimplantar aplicativos e recriar os dados necessários para esses casos. 

 Por exemplo, o Amazon EMR executa todos os nós de um determinado cluster na mesma zona de disponibilidade, pois a execução de um cluster na mesma zona melhora a performance dos fluxos de trabalho, pois fornece uma taxa de acesso a dados mais alta. Se esse componente for necessário para a resiliência da workload, você deverá ter uma maneira de reimplantar o cluster e seus dados. Além disso, para o Amazon EMR, você deve provisionar redundância de maneiras diferentes de usar o Multi-AZ. Você pode provisionar [vários nós](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Usando o [EMR File System (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), os dados no EMR podem ser armazenados no Amazon S3, que, por sua vez, podem ser replicados em várias zonas de disponibilidade ou Regiões da AWS. 

 Da mesma forma, o Amazon Redshift, por padrão, provisiona o cluster em uma zona de disponibilidade escolhida aleatoriamente dentro da Região da AWS selecionada. Todos os nós de cluster são provisionados na mesma zona. 

 Para workloads com estado baseadas em servidor e implantadas em um datacenter on-premises, é possível usar o Recuperação de desastres do AWS Elastic para proteger as workloads na AWS. Se você já estiver hospedado na AWS, poderá usar o Elastic Disaster Recovery para proteger a workload em uma zona de disponibilidade ou região alternativa. O Elastic Disaster Recovery usa a replicação contínua no nível de bloco para uma área de preparação leve visando fornecer recuperação rápida e confiável de aplicações on-premises e na nuvem. 

 **Etapas da implementação** 

1.  Implemente a autorreparação. Quando possível, use a escalabilidade automática para implantar instâncias ou contêineres. Quando não for possível, use a recuperação automática de instâncias do EC2 ou implemente a automação de autorreparação com base nos eventos de ciclo de vida do contêiner do Amazon EC2 ou do ECS. 
   +  Use os [grupos do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) para workloads de contêiner e instâncias que não têm requisitos para um endereço IP de instância única, endereço IP privado, endereço IP elástico e metadados da instância. 
     +  Os dados do usuário do modelo de execução podem ser usados para implementar uma automação que pode recuperar automaticamente a maioria das workloads. 
   +  Use a [recuperação automática de instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) para workloads que exijam um único endereço de ID da instância, endereço IP privado, endereço IP elástico e metadados da instância. 
     +  A recuperação automática enviará alertas de status de recuperação para um tópico do SNS quando a falha na instância for detectada. 
   +  Use os [eventos do ciclo de vida da instância do Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) ou os [eventos do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) para automatizar a autorreparação, em que não seja possível usar a escalabilidade automática ou a recuperação do EC2. 
     +  Use os eventos para chamar a automação que recuperará seu componente de acordo com a lógica do processo necessária. 
   +  Proteja workloads com estado que são limitadas a um único local usando o [Recuperação de desastres do AWS Elastic](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Eventos do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) 
+  [Ganchos do ciclo de vida do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) 
+  [Recupere sua instância.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) 
+  [Escalabilidade automática do serviço](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) 
+  [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
+ [Recuperação de desastres do AWS Elastic](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

# REL10-BP04 Usar arquiteturas de anteparo para limitar o escopo de impacto
<a name="rel_fault_isolation_use_bulkhead"></a>

Implemente arquiteturas de anteparo (também chamadas de arquiteturas baseadas em células) para restringir o efeito ou a falha em uma workload a um número limitado de componentes.

 **Resultado desejado:** uma arquitetura baseada em células usa várias instâncias isoladas de uma workload, em que cada instância é considerada uma célula. Cada célula é independente, não compartilha o estado com outras células e processa um subconjunto das solicitações gerais da workload. Isso reduz o possível impacto de uma falha, como uma atualização de software incorreta, a uma célula individual e às solicitações que ela está processando. Se uma workload usa 10 células para atender a 100 solicitações, quando ocorre uma falha, 90% das solicitações gerais não seriam afetadas pela falha. 

 **Antipadrões comuns:** 
+  Permitir que as células cresçam sem limites. 
+  Aplicar implantações ou atualizações de código a todas as células ao mesmo tempo. 
+  Compartilhar o estado ou os componentes entre as células (com a exceção da camada do roteador). 
+  Adicionar negócios complexos ou rotear lógica para a camada do roteador. 
+  Não minimizar as interações entre as células. 

 **Benefícios do estabelecimento dessa prática recomendada:** com arquiteturas baseadas em células, muitos tipos comuns de falhas são contidas na própria célula, fornecendo isolamento de falhas adicional. Esses limites de falhas podem fornecer resiliência com relação a tipos de falha que, de outra maneira, seriam difíceis de conter, como implantações de código sem êxito ou solicitações corrompidas ou que acionam um modo de falha específico (também conhecidas como *solicitações com conteúdo malicioso*). 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Em um navio, as anteparas garantem que uma ruptura no casco seja contida em uma seção do casco. Em sistemas complexos, esse padrão costuma ser replicado para permitir o isolamento de falhas. Os limites isolados de falhas restringem o efeito de uma falha em uma workload a um número controlado de componentes. A falha não afeta os componentes fora do limite. Ao usar vários limites isolados de falhas, você pode restringir o impacto sobre sua carga de trabalho. Na AWS, os clientes podem usar várias zonas de disponibilidade e regiões para fornecer o isolamento de falhas, mas o conceito do isolamento de falhas também pode ser estendido à arquitetura da workload. 

 A workload geral é composta por células particionadas por uma chave de partição. Essa chave precisa se alinhar à *granularidade* do serviço, ou da maneira natural que a workload de um serviço pode ser subdividida em interações mínimas entre células. Exemplos de chaves de partição são ID de cliente, ID de recurso ou qualquer outro parâmetro facilmente acessível na maioria das chamadas de API. Uma camada de roteamento de célula distribui solicitações a células individuais com base na chave de partição e apresenta um único endpoint aos clientes. 

![\[Diagrama mostrando arquitetura baseada em células\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/cell-based-architecture.png)


 **Etapas da implementação** 

 Ao projetar uma arquitetura baseada em células, há várias considerações de design a levar em conta: 

1.  **Chave de partição**: deve-se dedicar uma consideração especial ao escolher a chave de partição. 
   +  Ela precisa se alinhar à granularidade do serviço, ou da maneira natural que a workload de um serviço pode ser subdividida em interações mínimas entre células. Dentre os exemplos estão o `ID de cliente` ou `ID de recurso`. 
   +  A chave de partição deve estar disponível em todas as solicitações, seja diretamente ou de uma maneira que possa ser facilmente inferida de forma determinística por outros parâmetros. 

1.  **Mapeamento de células persistentes**: os serviços de upstream só devem interagir com uma única célula pelo ciclo de vida dos recursos. 
   +  Dependendo da workload, uma estratégia de migração de células pode ser necessária para migrar os dados de uma célula para outra. Um possível cenário de quando é necessário fazer uma migração de célula seria quando um usuário ou recurso específico na workload fica grande demais e exige uma célula dedicada. 
   +  As células não devem compartilhar estado ou componentes entre si. 
   +  Consequentemente, as interações entre as células devem ser evitadas e mantidas no mínimo, já que elas podem criar dependências entre as células e, assim, reduzir as melhorias do isolamento de falhas. 

1.  **Camada do roteador**: a camada do roteador é um componente compartilhado entre células e, portanto, não pode seguir a mesma estratégia de compartimentalização das células. 
   +  É recomendável que a camada do roteador distribua as solicitações para células individuais usando um algoritmo de mapeamento de partição de maneira computacionalmente eficiente, como combinando funções de hash criptográficas e aritmética modular para mapear chaves de partição a células. 
   +  Para evitar impactos em várias células, a camada de roteamento deve permanecer o mais simples e horizontalmente escalável possível, o que exige evitar uma lógica empresarial complexa nessa camada. Isso tem o benefício adicional de facilitar a compreensão de seu comportamento esperado em todos os momentos, permitindo uma capacidade de testes completa. Conforme explicado por Colm MacCárthaigh em [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) (Confiabilidade, trabalho constante e uma boa xícara de café), designs simples e padrões de trabalho constantes produzem sistemas confiáveis e reduzem a antifragilidade. 

1.  **Tamanho da célula**: as células devem ter um tamanho máximo e não devem ter permissão para crescer além disso. 
   +  O tamanho máximo deve ser identificado com a realização de testes completos, até que os pontos de ruptura sejam atingidos e as margens operacionais seguras sejam estabelecidas. Para obter mais detalhes sobre como implementar práticas de testes, consulte [REL07-BP04 Fazer o teste de carga da sua workload](rel_adapt_to_changes_load_tested_adapt.md) 
   +  A workload geral deve crescer com a adição de mais células, permitindo que a workload seja escalada com aumentos na demanda. 

1.  **Estratégias de várias zonas de disponibilidade ou várias regiões**: várias camadas de resiliência devem ser utilizadas para a proteção contra diferentes domínios de falha. 
   +  Para resiliência, você deve usar uma abordagem que crie camadas de defesa. Uma camada protege contra interrupções menores e mais comuns criando uma arquitetura altamente disponível usando várias AZs. Outra camada de defesa destina-se a proteger contra eventos raros, como desastres naturais generalizados e interrupções em nível regional. Essa segunda camada envolve arquitetar a aplicação para abranger várias Regiões da AWS. A implementação de uma estratégia multirregional para a workload ajuda a protegê-la contra desastres naturais generalizados, que afetam uma grande área geográfica de um país, ou falhas técnicas de escopo regional. Esteja ciente de que a implementação de uma arquitetura multirregional pode ser complexa e, geralmente, não é necessária para a maioria das workloads. Para obter mais detalhes, consulte [REL10-BP02 Escolher os locais apropriados para sua implantação de vários locais](rel_fault_isolation_select_location.md). 

1.  **Implantação de código**: uma estratégia de implantação de código escalonada deve ter preferência com relação à implantação de alterações de código em todas as células ao mesmo tempo. 
   +  Isso ajudará a reduzir a possibilidade de falhas em várias células devido a uma implantação incorreta ou a erro humano. Para obter mais detalhes, consulte [Automating safe, hands-off deployment](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) (Automatizar uma implantação prática e segura). 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL07-BP04 Fazer o teste de carga da sua workload](rel_adapt_to_changes_load_tested_adapt.md) 
+  [REL10-BP02 Escolher os locais apropriados para sua implantação de vários locais](rel_fault_isolation_select_location.md) 

 **Documentos relacionados:** 
+  [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) (Confiabilidade, trabalho constante e uma boa xícara de café) 
+ [AWS and Compartmentalization ](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/) (AWS e compartimentalização)
+ [isolamento de carga de trabalho usando fragmentos aleatórios](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+  [Automating safe, hands-off deployment](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) (Automatizar uma implantação prática e segura) 

 **Vídeos relacionados:** 
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)(AWS re:Invent 2018: fechar ciclos e abrir mentes: como controlar sistemas, sejam grandes ou pequenos)
+  [AWS re:Invent 2018: como a AWS reduz o impacto das falhas (ARC338)](https://youtu.be/swQbA4zub20) 
+  [Fragmentação aleatória: AWS re:Invent 2019: apresentação da Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373) 
+ [AWS Summit ANZ 2021: tudo falha o tempo todo: como criar o design visando a resiliência ](https://www.youtube.com/watch?v=wUzSeSfu1XA)

 **Exemplos relacionados:** 
+  [Laboratório do Well-Architected: isolamento de falhas com fragmentação aleatória](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/) 

# CONFIABILIDADE 11. Como projetar a workload para resistir a falhas de componentes?
<a name="rel-11"></a>

As cargas de trabalho que exigem alta disponibilidade e baixo Tempo médio até a recuperação (MTTR) devem ser projetadas visando a resiliência.

**Topics**
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Failover para recursos íntegros](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Usar estabilidade estática para evitar o comportamento bimodal](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade](rel_withstand_component_failures_notifications_sent_system.md)
+ [REL11-BP07 Arquitetar o produto para cumprir as metas de disponibilidade e os acordos de nível de serviço (SLAs) de tempo de atividade](rel_withstand_component_failures_service_level_agreements.md)

# REL11-BP01 Monitorar todos os componentes da workload para detectar falhas
<a name="rel_withstand_component_failures_monitoring_health"></a>

 Monitore constantemente a integridade da workload para que você e seus sistemas automatizados detectem falhas ou degradações assim que elas ocorrerem. Monitore os indicadores-chave de performance (KPIs) com base no valor empresarial. 

 Todos os mecanismos de reparo e recuperação devem começar com a capacidade de detectar problemas rapidamente. As falhas técnicas devem ser detectadas primeiro para que possam ser resolvidas. No entanto, a disponibilidade é baseada na capacidade da workload de entregar valor empresarial, portanto, os indicadores-chave de performance (KPIs) que medem isso precisam fazer parte da sua estratégia de detecção e remediação. 

 **Resultado desejado:** Os componentes essenciais de uma workload são monitorados de forma independente para detectar e alertar sobre falhas quando e onde elas acontecem. 

 **Antipadrões comuns:** 
+  Nenhum alarme foi configurado, portanto as interrupções ocorrem sem notificação. 
+  Os alarmes existem, mas com limites que não permitem um tempo adequado para reação. 
+  As métricas não são coletadas com frequência suficiente para atender ao objetivo de tempo de recuperação (RTO) 
+  Somente as interfaces da workload voltadas para o cliente são monitoradas ativamente. 
+  Coleta apenas das métricas técnicas, não das métricas de função de negócios. 
+  Não há métricas que medem a experiência do usuário da workload. 
+  São criados monitores em excesso. 

 **Benefícios de estabelecer esta prática recomendada:** O monitoramento adequado de todas as camadas permite reduzir o tempo de recuperação ao reduzir o tempo de detecção. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Identifique todas as workloads que serão analisadas para monitoramento. Depois de identificar todos os componentes da workload que precisarão ser monitorados, você precisará determinar o intervalo de monitoramento. O intervalo de monitoramento terá um impacto direto na rapidez com que a recuperação pode ser iniciada com base no tempo necessário para detectar uma falha. O tempo médio de detecção (MTTD) é a quantidade de tempo entre a ocorrência de uma falha e o início das operações de reparo. A lista de serviços deve ser extensa e completa. 

 O monitoramento deve abranger todas as camadas da pilha de aplicações, incluindo aplicação, plataforma, infraestrutura e rede. 

 Sua estratégia de monitoramento deve considerar o impacto de *falhas cinzentas*. Para obter mais detalhes sobre falhas cinzentas, consulte [ Falhas cinzentas](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) no whitepaper Advanced Multi-AZ Resilience Patterns (Padrões avançados de resiliência Multi-AZ). 

### Etapas da implementação
<a name="implementation-steps"></a>
+  O intervalo de monitoramento depende da rapidez com que você precisa fazer a recuperação. O tempo de recuperação é determinado pelo tempo necessário para a recuperação. Desse modo, você deve considerar esse tempo e o objetivo de tempo de recuperação (RTO) para determinar a frequência da coleta. 
+  Configure o monitoramento detalhado de componentes e serviços gerenciados. 
  +  Determine se [o monitoramento detalhado para instâncias do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) e [Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) são necessários. O monitoramento detalhado fornece métricas de intervalo de um minuto, e o monitoramento padrão fornece métricas de intervalo de cinco minutos. 
  +  Determine se [o monitoramento aprimorado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) para RDS é necessário. O monitoramento aprimorado usa um agente nas instâncias do RDS para obter informações úteis sobre processos ou threads diferentes. 
  +  Determine os requisitos de monitoramento de componentes essenciais sem servidor para [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html), o [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html), o [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html), o [Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs), e todos os tipos de [balanceadores de carga](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html). 
  +  Determine os requisitos de monitoramento dos componentes de armazenamento para [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html), o [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html), o [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html)e o [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html). 
+  Crie [métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) para medir os indicadores-chave de performance (KPIs) do negócio. As workloads implementam as principais funções empresariais, que devem ser usadas como KPIs para ajudar a identificar quando ocorre um problema indireto. 
+  Utilize os canários de usuário para monitorar a experiência do usuário e verificar se há falhas. [O teste de transação sintética](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (também conhecido como “teste canário”, que não deve ser confundido com “implantações canário”), que pode executar e simular o comportamento do cliente, está entre os processos de teste mais importantes. Execute esses testes constantemente nos endpoints da workload de diversos locais remotos. 
+  Crie [métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) que rastreiem a experiência do usuário. Se você puder estabelecer instrumentos de medição da experiência do cliente, conseguirá determinar o momento de degradação da experiência do consumidor. 
+  [Defina alarmes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) para detectar quando uma parte da workload não estiver funcionando corretamente e indicar quando deve ser feita a escalabilidade automática dos recursos. Os alarmes podem ser exibidos visualmente em painéis, enviar alertas pelo Amazon SNS ou por e-mail e trabalhar com o Auto Scaling para aumentar ou reduzir a escala dos recursos da workload. 
+  Crie [painéis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) para visualizar suas métricas. É possível usar os painéis para ver as tendências, os casos atípicos e outros indicadores de possíveis problemas ou para obter uma indicação de problemas a serem investigados. 
+  Crie [monitoramento de rastreamento distribuído](https://aws.amazon.com/xray/faqs/) para seus serviços. Com o monitoramento distribuído, você compreende como está a performance de sua aplicação e seus serviços subjacentes para identificar e solucionar a causa principal de problemas e erros de performance. 
+  Crie painéis de sistemas de monitoramento (usando [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) ou [X-Ray](https://aws.amazon.com/xray/faqs/)) e coleta de dados em uma Região e conta separadas. 
+  Crie integração para o monitoramento do [Amazon Health Aware](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) para permitir a visibilidade de monitoramento de recursos da AWS que possam ter degradações. Para workloads essenciais aos negócios, essa solução fornece acesso a alertas proativos e em tempo real para serviços da AWS. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 

 **Documentos relacionados:** 
+  [Amazon CloudWatch Synthetics permite criar canários de usuário](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [Habilitar ou desabilitar o monitoramento detalhado da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) 
+  [Monitoramento aprimorado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) 
+  [Monitoramento de grupos e instâncias do Auto Scaling usando o Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) 
+  [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Uso dos alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Uso de painéis do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Uso de painéis do CloudWatch entre regiões e contas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) 
+  [Uso do rastreamento do X-Ray entre regiões e contas](https://aws.amazon.com/xray/faqs/) 
+  [Compreensão da disponibilidade](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html) 
+  [Implementação do Amazon Health Aware (AHA)](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) 

 **Vídeos relacionados:** 
+  [Mitigating gray failures (Mitigando falhas cinzentas)](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) 

 **Exemplos relacionados:** 
+  [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) 
+  [Um workshop de observabilidade: explore o X-Ray](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray) 

 **Ferramentas relacionadas:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP02 Failover para recursos íntegros
<a name="rel_withstand_component_failures_failover2good"></a>

 Se ocorrer uma falha no recurso, os recursos íntegros deverão continuar atendendo às solicitações. Para falhas de localização (como zona de disponibilidade ou Região da AWS), garanta que você tenha sistemas implementados para realizar failover para recursos íntegros em locais sem problemas. 

 Ao projetar um serviço, distribua a carga entre recursos, zonas de disponibilidade ou regiões. Portanto, a falha ou a deficiência de um recurso individual podem ser atenuadas transferindo o tráfego para os recursos íntegros restantes. Pense em como os serviços são descobertos e encaminhados em caso de falha. 

 Projete seus serviços pensando na recuperação de falhas. Na AWS, projetamos os serviços para minimizar o tempo para recuperação de falhas e o impacto sobre os dados. Nossos serviços usam principalmente datastores que reconhecem solicitações apenas após serem armazenadas de modo durável entre várias réplicas em uma região. Eles são criados para usar isolamento com base em células e usar o isolamento de falhas fornecido por zonas de disponibilidade. Usamos automação amplamente em nossos procedimentos operacionais. Também otimizamos nossa funcionalidade de substituir e reiniciar para a recuperação rápida de interrupções. 

 Os padrões e os designs que permitem o failover variam para cada serviço de plataforma da AWS. Muitos serviços gerenciados nativos da AWS são nativamente várias zonas de disponibilidade (como o Lambda ou o API Gateway). Outros serviços da AWS (como EC2 e EKS) exigem designs específicos de práticas recomendadas para oferecer compatibilidade com o failover de recursos ou armazenamento de dados entre AZs. 

 O monitoramento deve ser configurado para conferir se o recurso de failover está íntegro, acompanhar o andamento do failover dos recursos e monitorar a recuperação do processo empresarial. 

 **Resultado desejado:** Os sistemas são capazes de usar novos recursos de forma automática ou manual para se recuperarem da degradação. 

 **Antipadrões comuns:** 
+  Planejar o fracasso não faz parte da fase de planejamento e design. 
+  O RTO e o RPO não são estabelecidos. 
+  Monitoramento insuficiente para detectar falhas nos recursos. 
+  Isolamento adequado dos domínios de falha. 
+  O failover multirregional não é considerado. 
+  A detecção de falhas é sensível ou agressiva demais ao decidir realizar o failover. 
+  Não testar nem validar o design de failover. 
+  Executar a automação de autorreparação sem notificar que a reparação era necessária. 
+  Falta de um período de amortecimento a fim de evitar falhas muito precoces. 

 **Benefícios de estabelecer esta prática recomendada:** Você pode criar sistemas mais resilientes que mantenham a confiabilidade em caso de falhas, degradando-se normalmente e se recuperando com rapidez. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Os serviços da AWS, como o [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) e o [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html), ajudam a distribuir a carga entre recursos e zonas de disponibilidade. Portanto, a falha de um recurso individual (como uma instância do EC2) ou o comprometimento de uma zona de disponibilidade podem ser atenuados desviando o tráfego para os recursos íntegros restantes. 

 Para workloads multirregionais, os projetos são mais complicados. Por exemplo, réplicas de leitura entre regiões permitem que você implante os dados em várias Regiões da AWS. No entanto, o failover ainda é necessário para promover a réplica de leitura como primária e direcionar seu tráfego para o novo endpoint. O Amazon Route 53, o Route 53, o ARC, o CloudFront e o AWS Global Accelerator podem ajudar a direcionar o tráfego entre Regiões da AWS. 

 Serviços da AWS, como Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge ou Amazon DynamoDB, são implantados automaticamente em várias zonas de disponibilidade pela AWS. Em caso de falha, esses serviços da AWS direcionam automaticamente o tráfego para locais íntegros. Os dados são armazenados de forma redundante em várias zonas de disponibilidade e permanecem disponíveis. 

 Para o Amazon RDS, o Amazon Aurora, o Amazon Redshift, o Amazon EKS ou o Amazon ECS, Multi-AZ é uma opção de configuração. A AWS poderá direcionar o tráfego para a instância íntegra se o failover for iniciado. Essa ação de failover pode ser realizada pela AWS ou conforme exigido pelo cliente. 

 Para instâncias do Amazon EC2, o Amazon Redshift, tarefas do Amazon ECS ou pods do Amazon EKS, você escolhe em quais zonas de disponibilidade implantar. Para alguns designs, o Elastic Load Balancing fornece a solução para detectar instâncias em zonas não íntegras e direcionar o tráfego para as zonas íntegras. O Elastic Load Balancing também pode rotear o tráfego para componentes em seu datacenter on-premises. 

 Para o failover de tráfego em várias regiões, o redirecionamento pode utilizar o Amazon Route 53, o ARC, o AWS Global Accelerator, o Route 53 Private DNS for VPCs ou o CloudFront para oferecer uma maneira de definir domínios da Internet e atribuir políticas de roteamento, incluindo verificações de integridade, para rotear o tráfego para regiões íntegras. O AWS Global Accelerator fornece endereços IP estáticos que atuam como um ponto de entrada fixo para sua aplicação e, depois, são roteados para os endpoints nas Regiões da AWS de sua escolha, usando a rede global da AWS em vez da Internet com o objetivo de melhorar o desempenho e a confiabilidade. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Crie designs de failover para todas as aplicações e serviços apropriados. Isole cada componente da arquitetura e crie designs de failover que atendam ao RTO e ao RPO de cada componente. 
+  Configure ambientes inferiores (como desenvolvimento ou teste) com todos os serviços necessários para ter um plano de failover. Implemente as soluções usando a infraestrutura como código (IaC) para garantir a repetibilidade. 
+  Configure um local de recuperação, como uma segunda região, para implementar e testar os designs de failover. Se necessário, os recursos para testes podem ser configurados temporariamente para limitar os custos adicionais. 
+  Determine quais planos de failover são automatizados pela AWS, quais podem ser automatizados por um processo de DevOps e quais podem ser manuais. Documente e avalie o RTO e o RPO de cada serviço. 
+  Crie um manual de failover e inclua todas as etapas para realizar o failover de cada recurso, aplicação e serviço. 
+  Crie um manual de failback e inclua todas as etapas de failback (com tempo) de cada recurso, aplicação e serviço. 
+  Crie um plano para iniciar e ensaiar o manual. Use simulações e testes de caos para testar a automação e as etapas do manual. 
+  Para danos na localização (como zona de disponibilidade ou Região da AWS), garanta que você tenha sistemas implementados para realizar failover para recursos íntegros em locais sem problemas. Confira a cota, os níveis de ajuste de escala automático e os recursos em execução antes do teste de failover. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [REL13 – Plano para DR](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) 
+  [REL10 – Usar o isolamento de falhas para proteger a workload](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) 

 **Documentos relacionados:** 
+  [Setting RTO and RPO Targets](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/) 
+  [Set up ARC with application loadbalancers](https://www.wellarchitectedlabs.com/reliability/disaster-recovery/workshop_5/) 
+  [Failover using Route 53 Weighted routing](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack) 
+  [DR with ARC](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/) 
+  [EC2 with autoscaling](https://github.com/adriaanbd/aws-asg-ecs-starter) 
+  [EC2 Deployments - Multi-AZ](https://github.com/awsdocs/amazon-ec2-auto-scaling-user-) 
+  [ECS Deployments - Multi-AZ](https://github.com/aws-samples/ecs-refarch-cloudformation) 
+  [Switch traffic using ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html) 
+  [Lambda with an Application Load Balancer and Failover](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html) 
+  [ACM Replication and Failover](https://github.com/aws-samples/amazon-ecr-cross-region-replication) 
+  [Parameter Store Replication and Failover](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d) 
+  [ECR cross region replication and Failover](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html) 
+  [Secrets manager cross region replication configuration](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html) 
+  [Enable cross region replication for EFS and Failover](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/) 
+  [EFS Cross Region Replication and Failover](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/) 
+  [Networking Failover](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html) 
+  [S3 Endpoint failover using MRAP](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap) 
+  [Create cross region replication for S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) 
+  [Failover Regional API Gateway with ARC](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjat_TNvev_AhVLlokEHaUeDSUQFnoECAYQAQ&url=https%3A%2F%2Fd1.awsstatic.com%2Fsolutions%2Fguidance%2Farchitecture-diagrams%2Fcross-region-failover-and-graceful-failback-on-aws.pdf&usg=AOvVaw0czthdzWiGlN9I-Dt0lAu3&opi=89978449) 
+  [Failover using multi-region global accelerator](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/) 
+  [Failover with DRS](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html) 
+  [Creating Disaster Recovery Mechanisms Using Amazon Route 53](https://amazon.awsapps.com/workdocs/index.html#/document/2501b1ab648225c2d50ab420c4626ef143834fd0d646978629e5ea4e9b8f014b) 

 **Exemplos relacionados:** 
+  [Recuperação de desastres na AWS](https://disaster-recovery.workshop.aws/en/) 
+  [Recuperação elástica de desastres na AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US) 

# REL11-BP03 Automatizar a reparação em todas as camadas
<a name="rel_withstand_component_failures_auto_healing_system"></a>

 Após a detecção de uma falha, use recursos automatizados para executar ações de correção. As degradações podem ser corrigidas automaticamente por meio de mecanismos internos de serviço ou exigir que os recursos sejam reiniciados ou removidos por meio de ações de remediação. 

 Para aplicações autogerenciadas e reparação entre regiões, os projetos de recuperação e os processos de recuperação automatizados podem ser extraídos de [práticas recomendadas existentes](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/). 

 A capacidade de reiniciar ou remover um recurso é uma ferramenta importante para corrigir falhas. Uma prática recomendada é deixar os serviços sem estado sempre que possível. Isso evita a perda de dados ou a disponibilidade na reinicialização do recurso. Na nuvem, você pode (e geralmente deve) substituir todo o recurso (por exemplo, uma instância de computação ou função sem servidor) como parte da reinicialização. A reinicialização em si é uma maneira simples e confiável de se recuperar de falhas. Muitos tipos diferentes de falhas ocorrem em cargas de trabalho. As falhas podem ocorrer em hardware, software, comunicações e operações. 

 Reiniciar ou tentar novamente também se aplica às solicitações de rede. Aplique a mesma abordagem de recuperação tanto a um tempo limite de rede quanto a uma falha de dependência em que a dependência retorna um erro. Ambos os eventos têm um efeito similar sobre o sistema, assim, em vez de tentar tornar qualquer um dos eventos um caso especial, aplique uma estratégia similar de nova tentativa limitada com recuo e variação exponenciais. A capacidade de reiniciar é um mecanismo de recuperação presente na computação orientada para a recuperação e arquiteturas de cluster de alta disponibilidade. 

 **Resultado desejado:** Ações automatizadas são executadas para corrigir a detecção de uma falha. 

 **Antipadrões comuns:** 
+  Provisionamento de recursos sem dimensionamento automático. 
+  Implantação de aplicações em instâncias ou contêineres individualmente. 
+  Implantação de aplicações que não podem ser implantadas em vários locais sem usar a recuperação automática. 
+  Reparação manual de aplicações que não são reparadas por meio do ajuste de escala automático e recuperação automática. 
+  Sem automação para failover nos bancos de dados. 
+  Não há métodos automatizados para redirecionar o tráfego para novos endpoints. 
+  Sem replicação de armazenamento. 

 **Benefícios de estabelecer esta prática recomendada:** A reparação automatizada pode reduzir seu tempo médio de recuperação e melhorar sua disponibilidade. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Os designs para Amazon EKS ou outros serviços do Kubernetes devem incluir conjuntos mínimos e máximos de réplicas ou com estado e tamanho mínimo do cluster e do grupo de nós. Esses mecanismos fornecem uma quantidade mínima de recursos de processamento continuamente disponíveis e, ao mesmo tempo, remediam automaticamente quaisquer falhas usando o ambiente de gerenciamento do Kubernetes. 

 Os padrões de design que são acessados por meio de um balanceador de carga usando clusters de computação devem utilizar grupos Auto Scaling. O Elastic Load Balancing (ELB) distribui automaticamente o tráfego de entrada da aplicação entre vários destinos e dispositivos virtuais em uma ou mais Zonas de Disponibilidade (AZs). 

 Designs baseados em computação em cluster que não usam balanceamento de carga devem ter seu tamanho projetado para a perda de pelo menos um nó. Isso permitirá que o serviço se mantenha funcionando em uma capacidade potencialmente reduzida enquanto recupera um novo nó. Entre os exemplos de serviço estão Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK e Amazon OpenSearch Service. Muitos desses serviços podem ser projetados com recursos adicionais de recuperação automática. Algumas tecnologias de cluster devem gerar um alerta sobre a perda de um nó, acionando um fluxo de trabalho automático ou manual para recriar um novo nó. Esse fluxo de trabalho pode ser automatizado usando o AWS Systems Manager para corrigir problemas rapidamente. 

 É possível usar o Amazon EventBridge para monitorar e filtrar eventos, como alarmes do CloudWatch ou alterações no estado de outros serviços da AWS. Com base nas informações do evento, ele pode então invocar AWS Lambda, Systems Manager Automation ou outros destinos para executar uma lógica de remediação personalizada na workload. O Amazon EC2 Auto Scaling pode ser configurado para verificar a integridade da instância EC2. Se a instância estiver em qualquer estado que não seja em execução, ou se o status do sistema for prejudicado, o Amazon EC2 Auto Scaling considerará que essa instância não é íntegra e executará uma instância de substituição. Para substituições em grande escala (como a perda de uma Zona de Disponibilidade inteira), a estabilidade estática é preferida para alta disponibilidade. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Use grupos do Auto Scaling para implantar camadas em uma workload. [O Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) pode executar a autorreparação em aplicações sem estado e adicionar e remover capacidade. 
+  Para instâncias computacionais mencionadas anteriormente, use [balanceamento de carga](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) e escolha o tipo apropriado de balanceador de carga. 
+  Considere a recuperação para Amazon RDS. Com instâncias em espera, configure para [failover automático](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds) para a instância em espera. Para a réplica de leitura do Amazon RDS, é necessário um fluxo de trabalho automatizado para tornar uma réplica de leitura primária. 
+  Implemente [recuperação automática em instâncias do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) que têm aplicações implantadas que não podem estar em vários locais e podem tolerar a reinicialização em caso de falhas. É possível usar a recuperação automática para substituir o hardware com falha e reiniciar a instância quando a aplicação não puder ser implantada em vários locais. Os metadados da instância e os endereços IP associados são mantidos, bem como os [volumes do EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) e pontos de montagem no [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) ou [sistemas de arquivos para Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) e [Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). Com o uso do [AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html), é possível configurar a autorreparação das instâncias do EC2 no nível da camada. 
+  Implemente a recuperação automatizada usando o [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) e o [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) quando não for possível usar o ajuste de escala automático ou a recuperação automática, ou quando a recuperação automática falhar. Quando não for possível usar o ajuste de escala automático e a recuperação automática ou quando a recuperação automática falhar, você poderá automatizar a reparação usando o AWS Step Functions e o AWS Lambda. 
+  [O Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) pode ser usado para monitorar e filtrar eventos como [alarmes do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) ou mudanças de estado em outros serviços da AWS. Com base nas informações do evento, ele pode invocar o AWS Lambda (ou outros destinos) para executar a lógica de correção personalizada na workload. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 

 **Documentos relacionados:** 
+  [Como funciona o AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [Recuperação automática do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) 
+  [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) 
+  [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) 
+  [O que é o Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) 
+  [O que é o Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) 
+  [AWS OpsWorks: como usar a correção automática para substituir instâncias com falha](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) 
+  [O que é o AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 
+  [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 
+  [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [Uso dos alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Failover do Amazon RDS](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf) 
+  [SSM - Automação do Systems Manager](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html) 
+  [Práticas recomendadas de arquitetura resiliente](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/) 

 **Vídeos relacionados:** 
+  [Provisionar e escalar automaticamente o OpenSearch Service](https://www.youtube.com/watch?v=GPQKetORzmE) 
+  [Failover automático do Amazon RDS](https://www.youtube.com/watch?v=Mu7fgHOzOn0) 

 **Exemplos relacionados:** 
+  [Workshop sobre Auto Scaling](https://catalog.workshops.aws/general-immersionday/en-US/advanced-modules/compute/auto-scaling) 
+  [Workshop de failover do Amazon RDS](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance) 

 **Ferramentas relacionadas:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação
<a name="rel_withstand_component_failures_avoid_control_plane"></a>

 Os ambientes de gerenciamento fornecem as APIs administrativas usadas para criar, ler e descrever, atualizar, excluir e listar recursos (CRUDL), enquanto os planos de dados lidam com o tráfego diário de serviços. Ao implementar respostas de recuperação ou mitigação a eventos potencialmente impactantes na resiliência, concentre-se em usar um número mínimo de operações do ambiente de gerenciamento para recuperar, redimensionar, restaurar, reparar ou realizar o failover do serviço. A ação do plano de dados deve substituir qualquer atividade durante esses eventos de degradação. 

 Por exemplo, estas são ações do ambiente de gerenciamento: iniciar uma nova instância de computação, criar armazenamento em bloco e descrever serviços de fila. Quando você executa instâncias de computação, o ambiente de gerenciamento precisa realizar várias tarefas, como encontrar um host físico com capacidade, alocar interfaces de rede, preparar volumes de armazenamento em blocos locais, gerar credenciais e adicionar regras de segurança. Os ambientes de gerenciamento tendem a ser uma orquestração complicada. 

 **Resultado desejado:** Quando um recurso entra em um estado comprometido, o sistema é capaz de se recuperar automática ou manualmente, transferindo o tráfego de recursos danificados para recursos saudáveis. 

 **Antipadrões comuns:** 
+  Dependência da alteração dos registros DNS para redirecionar o tráfego. 
+  Dependência das operações de escalonamento do ambiente de gerenciamento para substituir componentes danificados devido a recursos insuficientemente provisionados. 
+  Dependência de ações de ambiente de gerenciamento abrangentes, com vários serviços e várias APIs para remediar qualquer categoria de deficiência. 

 **Benefícios de estabelecer esta prática recomendada:** O aumento da taxa de sucesso da remediação automatizada pode reduzir seu tempo médio de recuperação e melhorar a disponibilidade da workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** médio: para certos tipos de degradação do serviço, os ambientes de gerenciamento são afetados. As dependências do uso extensivo do ambiente de gerenciamento para remediação podem aumentar o tempo de recuperação (RTO) e o tempo médio de recuperação (MTTR). 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Para limitar as ações do plano de dados, avalie cada serviço quanto às ações necessárias para restaurar o serviço. 

 Use o Amazon Application Recovery Controller (ARC) para mudar o tráfego de DNS. Esses recursos monitoram continuamente a capacidade da aplicação de se recuperar de falhas, permitindo que você controle a recuperação da aplicação em várias Regiões da AWS, Zonas de Disponibilidade e ambientes on-premises. 

 As políticas de roteamento do Route 53 usam o ambiente de gerenciamento. Portanto, não confie nele para recuperação. Os planos de dados do Route 53 respondem as consultas ao DNS, além de realizarem e avaliarem verificações de integridade. Eles são distribuídos globalmente e projetados para um [Acordo de Serviço (SLA) de 100% de disponibilidade](https://aws.amazon.com/route53/sla/). 

 As APIs e consoles de gerenciamento do Route 53 usados para criar, atualizar e excluir recursos do Route 53 são executados em ambientes de gerenciamento projetados para priorizar a consistência e a durabilidade necessária para gerenciar o DNS. Para que isso aconteça, os ambientes de gerenciamento estão localizados em uma única região: Leste dos EUA (Norte da Virgínia). Embora ambos os sistemas sejam construídos para serem muito confiáveis, os ambientes de gerenciamento não estão incluídos no SLA. Pode ser que ocorram raros eventos onde o design resiliente do plano de dados permita que ele mantenha a disponibilidade, enquanto os ambientes de gerenciamento não. Para mecanismos de recuperação de desastres e failover, use funções de plano de dados para fornecer a melhor confiabilidade possível. 

 Para o Amazon EC2, use designs de estabilidade estática para limitar as ações do ambiente de gerenciamento. As ações do ambiente de gerenciamento incluem a ampliação de recursos individualmente ou usando grupos do Auto Scaling (ASG). Para obter os níveis mais altos de resiliência, provisione capacidade suficiente no cluster usado para failover. Se essa capacidade precisar ser limitada, defina valores no sistema geral completo para definir com segurança o tráfego total que atinge o conjunto limitado de recursos. 

 Para serviços como Amazon DynamoDB, Amazon API Gateway, balanceadores de carga e AWS Lambda sem servidor, o uso aproveita o plano de dados. No entanto, criar novas funções, balanceadores de carga, gateways de API ou tabelas de DynamoDB é uma ação do ambiente de gerenciamento e deve ser concluída antes da degradação, como preparação para um evento e ensaio das ações de failover. Para o Amazon RDS, as ações do plano de dados permitem o acesso aos dados. 

 Para obter mais informações sobre planos de dados, ambientes de gerenciamento e como a AWS cria serviços para atender metas de alta disponibilidade, consulte [Estabilidade estática usando Zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/). 

 Entenda quais operações estão no plano de dados e quais estão no ambiente de gerenciamento. 

### Etapas da implementação
<a name="implementation-steps"></a>

 Para cada workload que precisa ser restaurada após um evento de degradação, avalie o runbook de failover, o projeto de alta disponibilidade, o projeto de recuperação automática ou o plano de restauração de recursos de HA. Identifique cada ação que pode ser considerada uma ação do ambiente de gerenciamento. 

 Considere alterar a ação de gerenciamento para uma ação do plano de dados: 
+  Auto Scaling (ambiente de gerenciamento) em comparação com recursos do Amazon EC2 pré-escalados (plano de dados) 
+  Migre para Lambda e seus métodos de escalabilidade (plano de dados) ou Amazon EC2 e ASG (ambiente de gerenciamento) 
+  Avalie qualquer projeto usando o Kubernetes e a natureza das ações do ambiente de gerenciamento. Adicionar pods é uma ação do plano de dados no Kubernetes. As ações devem se limitar à adição de pods e não adição de nós. O uso de [nós com provisionamento excessivo](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) é o método preferido para limitar as ações do ambiente de gerenciamento 

 Considere abordagens alternativas que permitam que as ações do plano de dados afetem a mesma remediação. 
+  Alteração de registro Route 53 (ambiente de gerenciamento) ou ARC (plano de dados) 
+ [ Verificações de integridade do Route 53 para atualizações mais automatizadas ](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)

 Se o serviço for essencial, considere alguns serviços em uma região secundária para permitir mais ações no ambiente de gerenciamento e no plano de dados em uma região não afetada. 
+  Amazon EC2 Auto Scaling ou Amazon EKS em uma região primária em comparação com Amazon EC2 Auto Scaling ou Amazon EKS em uma região secundária e roteando o tráfego para a região secundária (ação do ambiente de gerenciamento). 
+  Faça uma réplica de leitura na primária secundária ou tente a mesma ação na região primária (ação do ambiente de gerenciamento). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 

 **Documentos relacionados:** 
+  [Parceiro da APN: parceiros que podem ajudar na automação da sua tolerância a falhas](https://aws.amazon.com/partners/find/results/?keyword=automation) 
+  [AWS Marketplace: produtos que podem ser usados para tolerância a falhas](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) 
+  [Amazon Builders’ Library: evite a sobrecarga em sistemas distribuídos colocando o menor serviço no controle](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) 
+  [API do Amazon DynamoDB (ambiente de gerenciamento e plano de dados)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html) 
+  [Execuções do AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (divididas entre o ambiente de gerenciamento e o plano de dados) 
+  [Plano de dados do AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html) 
+  [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) 
+  [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 2: pilha multirregional](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) 
+  [Criação de mecanismos de recuperação de desastres usando o Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) 
+  [O que é o Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+ [ Ambiente de gerenciamento e plano de dados do Kubernetes ](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)

 **Vídeos relacionados:** 
+ [ Back to Basics - Using Static Stability (De volta ao básico: uso da estabilidade estática) ](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [ Building resilient multi-site workloads using AWS global services (Criação de workloads resilientes em vários sites usando serviços globais da AWS) ](https://www.youtube.com/watch?v=62ZQHTruBnk)

 **Exemplos relacionados:** 
+  [Introdução ao Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/) 
+ [ Amazon Builders’ Library: evite a sobrecarga em sistemas distribuídos colocando o menor serviço no controle ](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [ Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única ](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [ Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 2: pilha multirregional ](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [ Estabilidade estática usando Zonas de disponibilidade ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)

 **Ferramentas relacionadas:** 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)

# REL11-BP05 Usar estabilidade estática para evitar o comportamento bimodal
<a name="rel_withstand_component_failures_static_stability"></a>

 As workloads devem ser estaticamente estáveis e operar somente em um único modo normal. O comportamento bimodal ocorre quando a workload exibe um comportamento diferente nos modos normal e de falha. 

 Por exemplo, você pode tentar se recuperar de uma falha na zona de disponibilidade iniciando novas instâncias em uma zona de disponibilidade diferente. Isso pode resultar em uma resposta bimodal durante um modo de falha. Em vez disso, você deve criar workloads que sejam estaticamente estáveis e que operem em apenas um modo. Neste exemplo, essas instâncias deveriam ter sido provisionadas na segunda zona de disponibilidade antes da falha. Esse design de estabilidade estática verifica se a workload opera somente em um único modo. 

 **Resultado desejado:** As workloads não apresentam comportamento bimodal durante os modos normal e de falha. 

 **Antipadrões comuns:** 
+  Supor que os recursos sempre possam ser provisionados, independentemente do escopo da falha. 
+  Tentar adquirir recursos dinamicamente durante uma falha. 
+  Não provisionar recursos adequados entre zonas ou regiões até que ocorra uma falha. 
+  Pensar em projetos estáticos estáveis somente para recursos computacionais. 

 **Benefícios de estabelecer esta prática recomendada:** As workloads executadas com projetos estaticamente estáveis podem ter resultados previsíveis durante eventos normais e de falha. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 O comportamento bimodal ocorre quando a workload apresenta um comportamento diferente nos modos normal e de falha (por exemplo, depender da inicialização de novas instâncias se uma zona de disponibilidade falhar). Um exemplo de comportamento bimodal é quando projetos estáveis do Amazon EC2 provisionam instâncias suficientes em cada zona de disponibilidade para lidar com a carga da workload se uma AZ for removida. A integridade do Elastic Load Balancing ou do Amazon Route 53 conferiria a possibilidade de isolar a carga das instâncias prejudicadas. Depois que o tráfego for deslocado, use o AWS Auto Scaling para substituir de forma assíncrona instâncias da zona com falha e executá-las nas zonas íntegras. A estabilidade estática para implantação de computação (como instâncias ou contêineres do EC2) resulta na mais alta confiabilidade. 

![\[Diagrama mostrando a estabilidade estática de instâncias do EC2 em várias zonas de disponibilidade\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/static-stability.png)


 Isso deve ser comparado ao custo desse modelo e ao valor comercial de manter a workload em todos os casos de resiliência. É mais barato provisionar menos capacidade computacional e depender da inicialização de novas instâncias em caso de falha. No entanto, para falhas em grande escala (como um dano regional ou da zona de disponibilidade), essa abordagem é menos eficaz porque depende tanto de um plano operacional quanto de recursos suficientes disponíveis nas zonas ou regiões não afetadas. 

 A solução também deve comparar a confiabilidade com os custos necessários para a workload. As arquiteturas de estabilidade estática se aplicam a uma variedade de arquiteturas, incluindo instâncias de computação espalhadas por zonas de disponibilidade, projetos de réplicas de leitura de banco de dados, projetos de cluster do Kubernetes (Amazon EKS) e arquiteturas de failover de várias regiões. 

 Também é possível implementar um design mais estável estaticamente usando mais recursos em cada zona. Ao adicionar mais zonas, você reduz a quantidade de computação adicional necessária para a estabilidade estática. 

 Um exemplo de comportamento bimodal seria um tempo limite de rede que poderia fazer com que um sistema tentasse atualizar seu próprio estado de configuração por completo. Isso adicionaria uma carga inesperada a outro componente e poderia fazê-lo falhar, resultando em outras consequências inesperadas. Esse ciclo de feedback negativo afeta a disponibilidade da workload. Em vez disso, você pode criar sistemas estaticamente estáveis e operar em apenas um modo. Um design estático estável faria um trabalho constante e sempre atualizaria o estado da configuração em um ritmo fixo. Quando uma chamada falha, a workload usa o valor previamente armazenado em cache e inicia um alarme. 

 Outro exemplo de comportamento bimodal é permitir que os clientes ignorem o cache da workload em caso de falhas. Essa pode parecer uma solução que acomoda as necessidades do cliente, mas pode alterar significativamente as demandas da workload e provavelmente resultar em falhas. 

 Avalie workloads importantes para determinar quais workloads exigem esse tipo de projeto de resiliência. Para as que são consideradas críticas, cada componente da aplicação deve ser revisado. Exemplos de tipos de serviço que exigem avaliações de estabilidade estática são: 
+  **Computação**: Amazon EC2, EKS-EC2, ECS-EC2, EMR-EC2 
+  **Bancos de dados**: Amazon Redshift, Amazon RDS, Amazon Aurora 
+  **Armazenamento**: Amazon S3 (Zona única), Amazon EFS (montagens), Amazon FSx (montagens) 
+  **Balanceadores de carga:** Em determinados projetos 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Crie sistemas que sejam estaticamente estáveis e que operem em apenas um modo. Nesse caso, provisione instâncias suficientes em cada zona de disponibilidade ou região para lidar com a capacidade da workload se uma zona de disponibilidade ou região for removida. Uma variedade de serviços pode ser usada para roteamento a recursos íntegros, como: 
  +  [Roteamento de DNS entre regiões](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) 
  +  [Roteamento de várias regiões do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) 
  +  [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) 
  +  [Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  Configure [réplicas de leitura do banco de dados](https://aws.amazon.com/rds/features/multi-az/) para contabilizar a perda de uma única instância principal ou de uma réplica de leitura. Se o tráfego estiver sendo servido por réplicas de leitura, a quantidade em cada zona de disponibilidade e cada região deve ser igual à necessidade geral em caso de falha na zona ou região. 
+  Configure dados importantes no armazenamento do Amazon S3, projetado para ser estaticamente estável para dados armazenados em caso de falha na zona de disponibilidade. Se [Se a classe de armazenamento Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) for usada, ela não deverá ser considerada estaticamente estável, pois a perda dessa zona minimiza o acesso a esses dados armazenados. 
+  [Às vezes, os balanceadores de carga](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) são configurados incorretamente ou intencionalmente para atender a uma zona de disponibilidade específica. Nesse caso, o design estaticamente estável pode envolver a distribuição de uma workload entre várias zonas de disponibilidade em um design mais complexo. O design original pode ser usado para reduzir o tráfego entre zonas por motivos de segurança, latência ou custo. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 
+  [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html) 

 **Documentos relacionados:** 
+  [Minimizar dependências em um plano de recuperação de desastres](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) 
+  [A Amazon Builders’ Library: estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 
+  [Limites de isolamento de falhas](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html) 
+  [Estabilidade estática usando Zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 
+  [Multi-AZ do Amazon RDS](https://aws.amazon.com/rds/features/multi-az/) 
+  [Minimizar dependências em um plano de recuperação de desastres](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) 
+  [Roteamento de DNS entre regiões](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) 
+  [Roteamento de várias regiões do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) 
+  [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) 
+  [ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [Zona única do Amazon S3](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) 
+  [Balanceamento de carga entre zonas](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) 

 **Vídeos relacionados:** 
+  [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704) 

 **Exemplos relacionados:** 
+  [A Amazon Builders’ Library: estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 

# REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade
<a name="rel_withstand_component_failures_notifications_sent_system"></a>

 As notificações são enviadas após a detecção de limites violados, mesmo que o evento causado pelo problema tenha sido resolvido automaticamente. 

 A correção automatizada permite que a workload seja confiável. No entanto, ele também pode obscurecer problemas subjacentes que precisam ser resolvidos. Implemente eventos e monitoramento apropriados para que você possa detectar padrões de problemas, incluindo aqueles abordados pela correção automática, para que você possa resolver problemas de causa-raiz. 

 Os sistemas resilientes são projetados para que os eventos de degradação sejam comunicados imediatamente às equipes apropriadas. Essas notificações devem ser enviadas por meio de um ou vários canais de comunicação. 

 **Resultado desejado: **Os alertas são enviados imediatamente às equipes de operações quando os limites são violados. Esses alertas podem incluir taxas de erro, latência ou outras métricas importantes de indicadores-chave de performance (KPI), permitindo que esses problemas sejam resolvidos o mais rápido possível e o impacto do usuário seja evitado ou minimizado. 

 **Antipadrões comuns:** 
+  Enviar muitos alarmes. 
+  Enviar alarmes que não resultam em ações concretas. 
+  Definir limites de alarme muito altos (supersensíveis) ou muito baixos (subsensíveis). 
+  Não enviar alarmes para dependências externas. 
+  Não considerar [falhas cinzentas](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) ao projetar monitoramento e alarmes. 
+  Executar a automação da correção, mas sem notificar a equipe apropriada de que a correção era necessária. 

 **Benefícios de estabelecer esta prática recomendada:** As notificações de recuperação alertam as equipes operacionais e empresariais sobre as degradações do serviço, para que possam reagir imediatamente a fim de minimizar o tempo médio de detecção (MTTD) e o tempo médio de reparo (MTTR). As notificações de eventos de recuperação também garantem que você não ignore problemas que ocorrem com pouca frequência. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio. A falha na implementação de mecanismos adequados de monitoramento e notificação de eventos pode resultar em falha na detecção de padrões de problemas, incluindo aqueles resolvidos pela recuperação automática. Uma equipe só será informada da degradação do sistema quando os usuários entrarem em contato com o atendimento ao cliente ou por acaso. 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Ao definir uma estratégia de monitoramento, um alarme acionado é um evento comum. Esse evento provavelmente conteria um identificador para o alarme, o estado do alarme (como `EM ALARME` ou `OK`) e detalhes do que o desencadeou. Em muitos casos, deve-se detectar um evento de alarme e enviar uma notificação por e-mail. Este é um exemplo de uma ação em um alarme. A notificação do alarme é fundamental para a observabilidade, pois informa às pessoas certas que há um problema. No entanto, quando a ação sobre eventos amadurece em sua solução de observabilidade, ela pode corrigir automaticamente o problema sem a necessidade de intervenção humana. 

 Depois que os alarmes de monitoramento de KPI forem estabelecidos, os alertas deverão ser enviados às equipes apropriadas quando os limites forem excedidos. Esses alertas também podem ser usados para acionar processos automatizados que tentarão remediar a degradação. 

 Para um monitoramento de limite mais complexo, considere alarmes compostos. Eles usam vários alarmes de monitoramento de KPI para criar um alerta com base na lógica operacional de negócios. Os alarmes do CloudWatch podem ser configurados para enviar e-mails ou registrar incidentes em sistemas de rastreamento de incidentes de terceiros usando a integração com o Amazon SNS ou Amazon EventBridge. 

### Etapas para a implementação
<a name="implementation-steps"></a>

 Crie vários tipos de alarme com base na forma como as workloads são monitoradas, por exemplo: 
+  Os alarmes de aplicações são usados para detectar quando alguma parte da workload não está funcionando adequadamente. 
+  [Alarmes de infraestrutura](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) indicam quando escalar os recursos. Os alarmes podem ser exibidos visualmente em painéis, enviar alertas pelo Amazon SNS ou por e-mail e trabalhar com o Auto Scaling para aumentar ou reduzir a escala dos recursos da workload horizontalmente. 
+  Simples [alarmes estáticos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) podem ser criados para monitorar quando uma métrica ultrapassa um limite estático durante um número específico de períodos de avaliação. 
+  [Os alarmes compostos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) podem representar alarmes complexos de várias origens. 
+  Depois que o alarme for criado, crie eventos de notificação apropriados. Você pode invocar diretamente uma [API do Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) para enviar notificações e vincular qualquer automação para correção ou comunicação. 
+  integre o [Amazon Health Aware](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) para permitir a visibilidade de monitoramento de recursos da AWS que possam ter degradações. Para workloads essenciais aos negócios, essa solução fornece acesso a alertas proativos e em tempo real para serviços da AWS. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas ao Well-Architected:** 
+  [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 

 **Documentos relacionados:** 
+  [Criar um alarme do CloudWatch com base em um limite estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) 
+  [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [O que é o Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 
+  [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Uso dos alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Amazon Health Aware (AHA)](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) 
+  [Setup CloudWatch Composite alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) 
+  [What's new in AWS Observability at re:Invent 2022](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/) 

 **Ferramentas relacionadas:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP07 Arquitetar o produto para cumprir as metas de disponibilidade e os acordos de nível de serviço (SLAs) de tempo de atividade
<a name="rel_withstand_component_failures_service_level_agreements"></a>

Arquitete o produto para cumprir as metas de disponibilidade e os acordos de nível de serviço (SLAs) de tempo de atividade. Se você publicar ou concordar de forma privada com as metas de disponibilidade ou SLAs de tempo de atividade, verifique se sua arquitetura e seus processos operacionais foram projetados para comportá-los. 

 **Resultado desejado:** cada aplicação tem uma meta definida com relação à disponibilidade e SLA para métricas de desempenho, o que pode ser monitorado e mantido para cumprir os resultados empresariais. 

 **Antipadrões comuns:** 
+  Planejar e implantar workloads sem definir SLAs. 
+  As métricas de SLA são definidas como altas sem justificativa ou requisitos empresariais. 
+  Definir SLAs sem considerar as dependências e o SLA subjacente. 
+  Os designs da aplicação são criados sem considerar o modelo de responsabilidade compartilhada para resiliência. 

 **Benefícios do estabelecimento dessa prática recomendada:** projetar aplicações com base nas principais metas de resiliência ajuda a cumprir os objetivos empresariais e atender às expectativas dos clientes. Esses objetivos ajudam a orientar o processo de design da aplicação que avalia diferentes tecnologias e considera as vantagens e desvantagens. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Os designs da aplicação precisam levar em conta um conjunto de requisitos diversos que são derivados dos objetivos empresariais, operacionais e financeiros. Nos requisitos operacionais, as workloads precisam ter metas de métricas de resiliência específicas para que possam ser monitorados e comportados adequadamente. As métricas de resiliência não devem ser definidas nem derivadas depois de implantar a workload. Elas devem ser definidas durante a fase de design e ajudar a orientar as diversas decisões e concessões. 
+  Cada workload deve ter seu próprio conjunto de métricas de resiliência. Essas métricas podem ser diferentes de outras aplicações empresariais. 
+  Reduzir as dependências pode ter um impacto positivo na disponibilidade. Cada workload deve considerar suas dependências e seus SLAs. Em geral, escolha dependências com metas de disponibilidade iguais ou maiores que as metas da workload. 
+  Considere designs com acoplamento fraco para que a workload possa operar corretamente apesar do comprometimento da dependência, quando possível. 
+  Reduza as dependências do ambiente de gerenciamento, especialmente durante uma recuperação ou degradação. Avalie os designs estaticamente estáveis com relação às workloads essenciais à missão. Use a economia de recursos para aumentar a disponibilidade dessas dependências em uma workload. 
+  A capacidade de observação e a instrumentalização são críticas para cumprir os SLAs reduzindo o tempo médio de detecção (MTTD) e o tempo médio de reparo (MTTR). 
+  Falha menos frequente (MTBF mais longo), tempo de detecção de falhas mais curto (MTTD mais curto) e tempo de reparo mais curto (MTTR mais curto) são os três fatores usados para melhorar a disponibilidade em sistemas distribuídos. 
+  Estabelecer e cumprir métricas de resiliência para uma workload é fundamental para qualquer design eficaz. Esses designs devem levar em consideração as vantagens e desvantagens da complexidade de design, as dependências do serviço, o desempenho, a escalabilidade e os custos. 

 **Etapas da implementação** 
+  Analise e documente o design da workload considerando as seguintes questões: 
  +  Onde são usados ambientes de gerenciamento na workload? 
  +  Como a workload implementa tolerância a falhas? 
  +  Quais são os padrões de design para componentes de escalabilidade, escalabilidade automática, redundância e alta disponibilidade? 
  +  Quais são os requisitos para disponibilidade e consistência de dados? 
  +  Há considerações quanto à economia de recursos ou estabilidade estática de recursos? 
  +  Quais são as dependências do serviço? 
+  Defina métricas de SLA com base na arquitetura da workload enquanto trabalha com as partes interessadas. Considere os SLAs de todas as dependências usadas pela workload. 
+  Quando a meta de SLA for definida, otimize a arquitetura para cumprir o SLA. 
+  Quando for definido o design que cumprirá o SLA, implemente mudanças operacionais, automação do processo e runbooks que também terão como foco uma redução de MTTD e MTTR. 
+  Depois da implantação, monitore e informe sobre o SLA. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md) 
+  [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md) 
+ [ Compreensão de integridade da workload ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)

 **Documentos relacionados:** 
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [ Pilar Confiabilidade: disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [ Measuring availability ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)(Medição da disponibilidade)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Modelo de responsabilidade compartilhada para resiliência ](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [estabilidade estática usando Zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [AWS Service Level Agreements (SLAs) ](https://aws.amazon.com/legal/service-level-agreements/)(Acordos de Nível de Serviço (SLAs) da AWS)
+ [ Guidance for Cell-based Architecture on AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)(Orientações para arquitetura baseada em células com a AWS)
+ [ Infraestrutura da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [ Advanced Multi-AZ Resiliance Patterns whitepaper ](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)(Whitepaper de padrões de resiliência Multi-AZ avançados)

 **Serviços relacionados:** 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)

# CONFIABILIDADE 12. Como testar a confiabilidade?
<a name="rel-12"></a>

Depois de projetar a workload para resiliência à pressão da produção, o teste é a única maneira de garantir que ela opere conforme projetado e com a resiliência esperada.

**Topics**
+ [REL12-BP01 Usar playbooks para investigar falhas](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Realizar análise pós-incidente](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Testar os requisitos funcionais](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 Testar os requisitos de escalabilidade e performance](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 Realizar dias de jogo regularmente](rel_testing_resiliency_game_days_resiliency.md)

# REL12-BP01 Usar playbooks para investigar falhas
<a name="rel_testing_resiliency_playbook_resiliency"></a>

 Faça a documentação do processo de investigação em playbooks para permitir respostas consistentes e rápidas em cenários de falha. Os playbooks são as etapas predefinidas executadas para identificar os fatores que contribuem para um cenário de falha. Os resultados de qualquer etapa do processo são usados para determinar as próximas etapas a serem seguidas até que o problema seja identificado ou encaminhado. 

 O playbook é um planejamento proativo que você deve fazer para poder executar ações reativas com eficácia. Quando cenários de falha não cobertos pelo playbook forem encontrados na produção, resolva primeiro o problema (apague o fogo). Em seguida, volte e veja as etapas que você seguiu para resolver o problema e use-as para adicionar uma nova entrada no playbook. 

 Observe que playbooks são usados em resposta a incidentes específicos, enquanto runbooks são usados para alcançar resultados específicos. Muitas vezes, runbooks são usados para atividades de rotina e os playbooks são usados para responder a eventos que não são rotineiros. 

 **Antipadrões comuns:** 
+  Planejar a implantação de uma carga de trabalho sem conhecer os processos para diagnosticar problemas ou responder a incidentes. 
+  Decisões não planejadas de quais sistemas coletar logs e métricas ao investigar um evento. 
+  Não armazenar as métricas e os eventos pelo tempo suficiente para recuperar os dados. 

 **Benefícios do estabelecimento desta prática recomendada:** Capturar playbooks garante que os processos possam ser seguidos de forma consistente. A codificação dos seus playbooks limita a introdução de erros por atividades manuais. A automação dos playbooks reduz o tempo de resposta a um evento ao eliminar a necessidade de intervenção de membros da equipe ou ao fornecer a eles informações adicionais desde o início da intervenção. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Use playbooks para identificar problemas. Os manuais são processos documentados para investigar problemas. Faça a documentação dos processos em playbooks para permitir respostas consistentes e rápidas em cenários de falha. Os playbooks devem incluir as informações e as diretrizes necessárias para que uma pessoa com as devidas qualificações colete as informações aplicáveis, identifique possíveis fontes de falha, isole as falhas e determine os fatores contribuintes (realize uma análise pós-incidente). 
  +  Implemente playbooks como código. Execute suas operações como código ao criar scripts de seus playbooks para garantir a consistência e reduzir os erros causados por processos manuais. Os playbooks podem ser compostos por vários scripts representando as diferentes etapas que podem ser necessárias para identificar os fatores que contribuem para um problema. As atividades do runbook podem ser acionadas ou executadas como parte das atividades do playbook, ou podem solicitar a execução de um playbook em resposta a eventos identificados. 
    +  [Automatizar playbooks operacionais com o AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) 
    +  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
    +  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
    +  [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 
    +  [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
    +  [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
+  [Automatizar playbooks operacionais com o AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) 
+  [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Uso de canários (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 

 **Exemplos relacionados:** 
+  [Automating operations with Playbooks and Runbooks (Automatização de operações com manuais e runbooks)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

# REL12-BP02 Realizar análise pós-incidente
<a name="rel_testing_resiliency_rca_resiliency"></a>

 Analise os eventos que afetam o cliente e identifique os fatores contribuintes e os itens de ação preventiva. Use essas informações para desenvolver mitigações para limitar ou evitar recorrência. Desenvolva procedimentos para respostas rápidas e eficazes. Comunique os fatores contribuintes e as ações corretivas conforme apropriado, de acordo com o público-alvo. Tenha um método para comunicar essas causas a outras pessoas, conforme necessário. 

 Avalie por que os testes existentes não encontraram o problema. Adicione testes para esse caso se os testes ainda não existirem. 

 **Resultado desejado:** suas equipes têm uma abordagem consistente e acordada para lidar com a análise pós-incidente. Um mecanismo é o [processo de correção de erros (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/). O processo de COE ajuda as equipes a identificar, compreender e abordar as causas básicas dos incidentes, ao mesmo tempo em que cria mecanismos e barreiras de proteção para limitar a probabilidade do mesmo incidente ocorrer novamente. 

 **Antipadrões comuns:** 
+  Encontrar fatores contribuintes, mas não continuar buscando mais profundamente outros possíveis problemas e abordagens de mitigação. 
+  Identificar apenas as causas de erros humanos e não oferecer nenhum treinamento ou automação que possa evitar erros humanos. 
+  Concentrar-se em atribuir a culpa em vez de compreender a causa raiz, criando uma cultura de medo e impedindo a comunicação aberta. 
+  Não compartilhar insights, o que mantém as descobertas da análise de incidentes em um pequeno grupo e impede que outras pessoas se beneficiem das lições aprendidas. 
+  Não ter um mecanismo para capturar conhecimento institucional e, dessa forma, perder insights valiosos por não preservar as lições aprendidas na forma de práticas recomendadas atualizadas e resultando em incidentes repetidos com a mesma causa raiz ou similar. 

 **Benefícios do estabelecimento dessa prática recomendada:** a realização de análises pós-incidentes e o compartilhamento dos resultados permitem que outras workloads atenuem o risco caso tenham implementado os mesmos fatores contribuintes, além de possibilitar que elas implementem a mitigação ou a recuperação automatizada antes que ocorra um incidente. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Uma boa análise pós-incidente oferece oportunidades para propor soluções comuns a problemas com padrões de arquitetura usados em outros locais nos sistemas. 

 A base do processo da COE é documentar e resolver problemas. É recomendável definir uma forma padronizada de documentar as causas raízes essenciais e garantir que elas sejam analisadas e abordadas. Atribua uma propriedade clara ao processo de análise pós-incidente. Designe uma equipe ou uma pessoa responsável para supervisionar as investigações e o acompanhamento de incidentes. 

 Incentive uma cultura que se concentre no aprendizado e na melhoria, em vez de na atribuição de culpas. Enfatize que a meta é evitar futuros incidentes, não penalizar pessoas. 

 Desenvolva procedimentos bem definidos para conduzir análises pós-incidentes. Esses procedimentos devem descrever as etapas a serem seguidas, as informações a serem coletadas e as principais questões a serem abordadas durante a análise. Investigue os incidentes minuciosamente, indo além das causas imediatas para identificar as causas raízes e os fatores contribuintes. Use técnicas, como os *[cinco porquês](https://en.wikipedia.org/wiki/Five_whys)*, para se aprofundar nos problemas subjacentes. 

 Mantenha um repositório das lições aprendidas com as análises dos incidentes. Esse conhecimento institucional pode servir como referência para futuros incidentes e iniciativas de prevenção. Compartilhe descobertas e insights de análises pós-incidentes e considere realizar reuniões abertas sobre a revisão pós-incidente para discutir as lições aprendidas. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Ao conduzir a análise pós-incidente, verifique se o processo está livre de culpabilização. Isso permite que as pessoas envolvidas no incidente sejam imparciais com as ações corretivas propostas e promovam uma autoavaliação honesta e a colaboração entre as equipes. 
+  Defina uma forma padronizada de documentar problemas essenciais. Um exemplo de estrutura para esse documento é o seguinte: 
  +  O que aconteceu? 
  +  Qual foi o impacto nos clientes e em sua empresa? 
  +  Qual foi a causa raiz? 
  +  Quais dados você tem para apoiar isso? 
    +  Por exemplo, métricas e grafos 
  +  Quais foram as implicações críticas nos pilares, especialmente em relação à segurança? 
    +  Ao arquitetar workloads, você faz concessões entre os pilares com base no contexto da sua empresa. Essas decisões de negócios podem definir suas prioridades de engenharia. Você pode reduzir custos e assim diminuir a confiabilidade em ambientes de desenvolvimento, ou otimizar a confiabilidade e aumentar os custos para soluções importantes. A segurança é sempre prioritária, porque você precisa proteger seus clientes. 
  +  Quais lições você aprendeu? 
  +  Quais ações corretivas você está tomando? 
    +  Itens de ação 
    +  Itens relacionados 
+  Crie procedimentos operacionais padrão bem definidos para conduzir análises pós-incidentes. 
+  Configure um processo padronizado de relatórios de incidentes. Documente todos os incidentes de forma abrangente, incluindo o relatório inicial do incidente, logs, comunicações e ações tomadas durante o incidente. 
+  Lembre-se de que um incidente não exige uma interrupção. Pode ser uma quase falha ou um sistema que, embora esteja funcionando de forma inesperada, cumpre sua função de negócios. 
+  Melhore continuamente o processo de análise pós-incidente com base no feedback e nas lições aprendidas. 
+  Capture as principais descobertas em um sistema de gerenciamento de conhecimento e considere os padrões que devem ser adicionados aos guias de desenvolvedor ou às listas de verificação de pré-implantação. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Why you should develop a correction of error (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) 

 **Vídeos relacionados:** 
+ [ Amazon’s approach to failing successfully ](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021 - Amazon Builders’ Library: Operational Excellence at Amazon ](https://www.youtube.com/watch?v=7MrD4VSLC_w)

# REL12-BP03 Testar os requisitos funcionais
<a name="rel_testing_resiliency_test_functional"></a>

 Use técnicas como testes de unidade e de integração que validam a funcionalidade necessária. 

 Você obtém os melhores resultados quando esses testes são executados automaticamente como parte das ações de compilação e implantação. Por exemplo, usando o AWS CodePipeline, os desenvolvedores confirmam alterações em um repositório de origem onde o CodePipeline detecta automaticamente as alterações. Essas alterações são criadas e os testes são executados. Após a conclusão dos testes, o código criado é implantado nos servidores de preparação para testes. No servidor de preparação, o CodePipeline executa mais testes, como testes de integração ou carga. Após a conclusão bem-sucedida desses testes, o CodePipeline implanta o código testado e aprovado nas instâncias de produção. 

 Além disso, a experiência mostra que o teste de transações sintéticas (também conhecido como *teste canário*, que não deve ser confundido com as implantações canário) que pode executar e simular o comportamento do cliente está entre os processos de teste mais importantes. Execute esses testes constantemente nos endpoints da carga de trabalho de diversos locais remotos. O Amazon CloudWatch Synthetics permite [criar canários](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) para monitorar seus endpoints e APIs. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Teste os requisitos funcionais. Esse procedimento inclui testes de unidade e de integração que validam a funcionalidade necessária. 
  +  [Usar o CodePipeline com o AWS CodeBuild para testar código e executar builds](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html) 
  +  [O AWS CodePipeline adiciona compatibilidade para testes de unidade e de integração personalizada com o AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) 
  +  [Entrega contínua e integração contínua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html) 
  +  [Uso de canários (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
  +  [Automação de teste de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro do APN: parceiros que podem ajudar na implementação de um pipeline de integração contínua](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration) 
+  [O AWS CodePipeline adiciona compatibilidade para testes de unidade e de integração personalizada com o AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) 
+  [AWS Marketplace: produtos que podem ser usados para integração contínua](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration) 
+  [Entrega contínua e integração contínua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html) 
+  [Automação de teste de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 
+  [Usar o CodePipeline com o AWS CodeBuild para testar código e executar builds](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html) 
+  [Uso de canários (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 

# REL12-BP04 Testar os requisitos de escalabilidade e performance
<a name="rel_testing_resiliency_test_non_functional"></a>

 Use técnicas como o teste de carga para validar se a workload atende aos requisitos de escalabilidade e performance. 

 Na nuvem, você pode criar um ambiente de teste em escala de produção sob demanda para sua carga de trabalho. Se você executar esses testes na infraestrutura reduzida, deverá escalar os resultados observados para o que você acha que acontecerá na produção. Os testes de carga e performance também podem ser feitos na produção se você tiver cuidado para não afetar os usuários reais e marcar seus dados de teste para que eles não se sintam com dados reais do usuário e estatísticas de uso corrompidas ou relatórios de produção. 

 Com os testes, certifique-se de que seus recursos básicos, configurações de escalabilidade, cotas de serviço e design de resiliência operem conforme o esperado sob carga. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Teste os requisitos de escalabilidade e performance. Execute o teste de carga para validar se a carga de trabalho atende aos requisitos de escalabilidade e performance. 
  +  [Distributed Load Testing on AWS: simulate thousands of connected users (Teste de carga distribuída na AWS: simular milhares de usuários conectados)](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
  +  [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected) 
    +  Implante seu aplicativo em um ambiente idêntico ao seu ambiente de produção e execute um teste de carga. 
      +  Use os conceitos de infraestrutura como código para criar um ambiente que seja o mais semelhante possível ao seu ambiente de produção. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Distributed Load Testing on AWS: simulate thousands of connected users (Teste de carga distribuída na AWS: simular milhares de usuários conectados)](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
+  [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected) 

# REL12-BP05 Testar a resiliência por meio da engenharia do caos
<a name="rel_testing_resiliency_failure_injection_resiliency"></a>

 Execute testes de caos regularmente em ambientes que estão em produção, ou muito próximos de entrarem em produção, para entender como seu sistema responde a condições adversas. 

 ** Resultado desejado: ** 

 A resiliência da workload é regularmente verificada por meio da aplicação de engenharia de caos na forma de testes de injeção de falha ou injeção de carga inesperada, além de testes de resiliência que validam o comportamento conhecido esperado da workload durante um evento. Combine engenharia de caos e testes de resiliência para ter confiança de que sua workload poderá sobreviver à falha de componentes e se recuperar de interferências inesperadas com pouco ou nenhum impacto. 

 ** Antipadrões comuns: ** 
+  Projetar para resiliência, mas não verificar como a workload funciona como um todo quando ocorrem falhas. 
+  Nunca realizar testes sob condições reais e carga esperada. 
+  Não tratar seus testes como código nem mantê-los ao longo do ciclo de desenvolvimento. 
+  Não realizar testes de caos tanto como parte do pipeline de CI/CD quanto fora das implantações. 
+  Negar o uso de análises pós-incidentes passadas ao determinar quais falhas usar para realizar testes. 

 ** Benefícios do estabelecimento desta prática recomendada:** A injeção de falhas para verificar a resiliência de uma workload permite que você obtenha confiança de que os procedimentos de recuperação de seu design resiliente vão funcionar em caso de falha real. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 A engenharia de caos proporciona à sua equipe os recursos para injetar continuamente interferências (simulações) reais de maneira controlada no provedor de serviço, na infraestrutura, na workload e no componente, com pouco ou nenhum impacto para os clientes. Permite que as equipes aprendam com as falhas e observem, mensurem e aumentem a resiliência das workloads, além de validar o acionamento de alertas e a notificação das equipes em caso de evento. 

 Quando realizada continuamente, a engenharia de caos pode destacar deficiências nas workloads que, se não respondidas, podem afetar negativamente a disponibilidade e a operação. 

**nota**  
A engenharia do caos é a disciplina de experimentar um sistema distribuído para aumentar a confiança na capacidade do sistema de resistir a condições turbulentas na produção. – [Princípios da engenharia do caos](https://principlesofchaos.org/) 

 Se um sistema é capaz de suportar essas interferências, os testes de caos devem ser mantidos como testes de regressão automatizados. Dessa forma, os testes de caos devem ser realizados como parte do ciclo de vida de desenvolvimento dos sistemas (SDLC) e como parte do pipeline de CI/CD. 

 Para garantir que sua workload pode sobreviver à falha de componentes, injete eventos reais como parte dos testes. Por exemplo, realize testes com perda de instâncias do Amazon EC2 ou failover da instância de banco de dados primária do Amazon RDS e verifique se a workload não é afetada (ou apenas minimamente afetada). Use uma combinação de falhas de componentes para simular eventos que podem ser causados por uma interferência em uma zona de disponibilidade. 

 Para falhas no nível da aplicação (como travamentos), você pode começar com fatores de estresse, como exaustão de memória e CPU. 

 Para validar [mecanismos de fallback ou failover](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) para dependências externas devido a interferências intermitentes na rede, os componentes devem simular esse tipo de evento bloqueando o acesso aos provedores externos durante um período especificado, que pode variar de segundos a horas. 

 Outros modos de degradação podem levar a uma redução nas funcionalidades e a respostas lentas, muitas vezes levando a uma interrupção dos serviços. Essa degradação costuma resultar de um aumento na latência de serviços críticos e comunicação de rede não confiável (pacotes abandonados). Testes com essas falhas, incluindo efeitos de rede como latência, mensagens perdidas e falhas de DNS, podem incluir a incapacidade de resolver um nome, alcançar o serviço de DNS ou estabelecer conexões com serviços dependentes. 

 **Ferramentas de engenharia de caos:** 

 o AWS Fault Injection Service (AWS FIS) é um serviço totalmente gerenciado para a execução de experimentos de injeção de falha que podem ser usados como parte do pipeline de CD, ou fora do pipeline. O AWS FIS é uma boa opção para ser usado durante dias de jogo de engenharia de caos. Oferece suporte à introdução simultânea de falhas em diferentes tipos de recursos, incluindo Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon RDS. Essas falhas incluem encerramento de recursos, failovers forçados, esgotamento de CPU ou memória, controle de utilização, latência e perda de pacotes. Por ser integrado a alarmes do Amazon CloudWatch, você pode definir condições de parada como barreiras de proteção para reverter um teste se causar impacto inesperado. 

![\[Diagrama mostrando que o AWS Fault Injection Service se integra a recursos da AWS para permitir a execução de experimentos de injeção de falha para as workloads.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/fault-injection-simulator.png)


Existem também várias opções de terceiros para experimentos de injeção de falhas. Elas incluem ferramentas de código aberto, como o [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/)e aos [Litmus Chaos](https://litmuschaos.io/), bem como opções comerciais como o Gremlin. Para expandir o escopo de falhas que podem ser injetadas na AWS, o AWS FIS [integra-se ao Chaos Mesh e Litmus Chaos](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/), possibilitando que você coordene fluxos de trabalho de injeção de falhas entre várias ferramentas. Por exemplo, você pode executar um teste de estresse na CPU de um pod usando falhas do Chaos Mesh ou Litmus enquanto encerra uma porcentagem selecionada aleatoriamente de nós de cluster usando ações de falha do AWS FIS. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Determine quais falhas usar para os testes. 

   Avalie o design de sua workload quanto à resiliência. Tais designs (criados usando as práticas recomendadas do [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) consideram riscos baseados em dependências críticas, eventos passados, problemas conhecidos e requisitos de conformidade. Liste cada elemento do design destinado a manter a resiliência e as falhas que foi projetado para mitigar. Para obter mais informações sobre a criação dessas listas, consulte o [artigo técnico Análise de prontidão operacional](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) que orienta você sobre como criar um processo para impedir a recorrência de incidentes passados. O processo de modos de falhas e análises de efeitos (FMEA) proporciona um framework para realização de análise de falhas em nível de componente e como elas afetam a workload. O FMEA foi descrito em mais detalhes por Adrian Cockcroft em [Failure Modes and Continuous Resilience (Modos de falhas e resiliência contínua)](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5). 
+  Atribua uma prioridade a cada falha. 

   Comece com uma categorização bruta, como alta, média e baixa. Para avaliar a prioridade, considere a frequência da falha e o impacto da falha na workload total. 

   Ao considerar a frequência de determinada falha, analise os dados passados para essa workload sempre que disponíveis. Caso contrário, use os dados de outras workloads executadas em ambientes semelhantes. 

   Ao considerar o impacto de determinada falha, em geral, quanto maior o escopo da falha, maior o impacto. Considere também o design e a finalidade da workload. Por exemplo, a capacidade de acessar os datastores de origem é essencial para uma workload que executa análise e transformação de dados. Nesse caso, priorize testes de falhas de acesso, além de acesso controlado e inserção de latência. 

   Análises pós-incidente são boas fontes de dados para entender a frequência e o impacto dos modos de falha. 

   Use a prioridade atribuída para determinar quais falhas escolher para testar primeiro e a sequência para desenvolver novos testes de injeção de falhas. 
+  Para cada teste realizado, siga o flywheel de engenharia de caos e resiliência contínua.   
![\[Diagrama do flywheel de engenharia de caos e resiliência contínua, mostrando as fases Melhoria, Estado estável, Hipótese, Executar teste e Verificar.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/chaos-engineering-flywheel.png)
  +  Defina o estado estável como uma saída mensurável de uma workload que indica comportamento normal. 

     Sua workload apresentará estado estável se estiver operando de maneira confiável e conforme o esperado. Portanto, valide a integridade da workload antes de definir o estado estável. O estado estável nem sempre significa que não há nenhum impacto à workload quando ocorre uma falha, já que determinada porcentagem de falhas pode estar dentro de limites aceitáveis. O estado estável é a linha de base que você vai observar durante o teste, o que vai destacar anomalias se a hipótese definida na próxima etapa não sair conforme o esperado. 

     Por exemplo, um estado estável de um sistema de pagamentos pode ser definido como o processamento de 300 TPS com taxa de sucesso de 99% e tempo de ida e volta de 500 ms. 
  +  Formule uma hipótese sobre como a workload vai reagir à falha. 

     Uma boa hipótese se baseia em como se espera que a workload mitigue a falha para manter o estado estável. A hipótese afirma que para determinado tipo de falha, o sistema ou a workload vai permanecer em estado estável, pois a workload foi projetada com mitigações específicas. O tipo específico de falhas e mitigações deve ser especificado na hipótese. 

     O modelo a seguir pode ser usado para a hipótese (mas outras palavras também são aceitáveis): 
**nota**  
 Se *falha específica* ocorrer, a workload *nome da workload* vai *descrever os controles de mitigação* para manter *impacto da métrica de negócios ou técnica*. 

     Por exemplo: 
    +  Se 20% dos nós no grupo de nós do Amazon EKS forem desativados, a API Transaction Create continuará atendendo ao 99.º percentil das solicitações em menos de 100 ms (estado estável). Os nós do Amazon EKS vão se recuperar em cinco minutos e os pods serão agendados e processarão o tráfego oito minutos depois do início do experimento. Os alertas serão acionados em três minutos. 
    +  Se ocorrer uma única falha de instância do Amazon EC2, a verificação de integridade do Elastic Load Balancing do sistema de ordem vai fazer com que o Elastic Load Balancing envie solicitações apenas para as instâncias íntegras restantes, enquanto o Amazon EC2 Auto Scaling substitui a instância com falha, mantendo um aumento inferior a 0,01% na quantidade de erros no servidor (5xx) (estado estável). 
    +  Se a instância de banco de dados primária do Amazon RDS falhar, a workload de coleta de dados da cadeia de suprimentos vai entrar em failover e se conectará à instância de banco de dados de espera do Amazon RDS para manter menos de um minuto de erros de leitura ou gravação de banco de dados (estado estável). 
  +  Execute o teste injetando a falha. 

     Um teste deve, por padrão, ser seguro contra falhas e tolerado pela workload. Se você sabe que a workload vai falhar, não execute o teste. A engenharia de caos deve ser usada para encontrar incertezas conhecidas ou desconhecidas. *Incertezas conhecidas* são coisas que você conhece, mas não entende totalmente, enquanto *incertezas desconhecidas* são coisas que você não conhece nem entende totalmente. Realizar testes em uma workload que você sabe que está quebrada não oferecerá novos insights. Seu teste deve ser cuidadosamente planejado, ter um escopo claro do impacto e fornecer um mecanismo de reversão que possa ser aplicado em caso de turbulência inesperada. Se sua devida diligência mostrar que a workload sobreviverá ao teste, prossiga com o teste. Há diversas opções para injetar as falhas. Para workloads na AWS, [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) oferece diversas simulações de falhas predefinidas chamadas de [ações](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). Você também pode definir ações personalizadas que são executadas no AWS FIS usando [documentos do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html). 

     Nós desencorajamos o uso de scripts personalizados para testes de caos, a menos que os scripts tenham os recursos para entender o estado atual da workload, sejam capazes de emitir logs e ofereçam mecanismos para rollbacks e condições de parada sempre que possível. 

     Um conjunto de ferramentas ou framework eficaz que ofereça suporte à engenharia de caos deve monitorar o estado atual de um experimento, emitir logs e fornecer mecanismos de rollback para oferecer suporte à execução controlada de um teste. Comece com um serviço estabelecido, como o AWS FIS, que permita que você realize testes com um escopo claramente definido e mecanismos de segurança que reverterão o teste se ele introduzir turbulência inesperada. Para conhecer uma ampla variedade de testes que usam o AWS FIS, consulte também o [laboratório Aplicações resilientes e bem-arquitetadas com engenharia de caos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). Além disso, o [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) vai analisar sua workload e criar testes que você pode escolher para implementação e execução no AWS FIS. 
**nota**  
 Para cada teste, entenda claramente o escopo e seu impacto. Recomendamos que as falhas sejam simuladas primeiro em um ambiente que não seja de produção, antes de serem executadas em produção. 

     Os testes devem ser executados em produção sob carga real usando [implantações canário](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) que ativam implantações de controle e experimentais no sistema, sempre que viável. A realização de testes durante horários fora de pico é uma boa prática para mitigar o impacto potencial durante o primeiro teste em produção. Além disso, se o uso de tráfego real de clientes for algo muito arriscado, você poderá executar testes usando tráfego sintético na infraestrutura de produção em implantações de controle e experimentais. Quando não for possível usar a produção, realize os testes em ambientes de pré-produção que sejam o mais parecido possível com produção. 

     Estabeleça e monitore barreiras de proteção para garantir que o teste não afete o tráfego de produção ou outros sistemas além dos limites aceitáveis. Estabeleça condições de parada para interromper um teste se ele atingir um limite definido de uma métrica de barreira de proteção. Isso deve incluir as métricas de estado estável da workload, bem como a métrica em relação aos componentes em que você está injetando a falha. A [monitor sintético](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (também conhecido como canário de usuário) é uma métrica que geralmente deve ser incluída como proxy de usuário. [Condições de parada do AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) são compatíveis como parte do modelo de teste, permitindo até cinco condições de parada por modelo. 

     Um dos princípios de caos é minimizar o escopo do teste e seu impacto: 

     embora deva existir uma provisão para algum impacto negativo de curto prazo, é responsabilidade e obrigação do engenheiro de caos garantir que as perdas dos testes sejam minimizadas e contidas. 

     Um método para verificar o escopo e o impacto potencial é realizar o teste primeiro em um ambiente que não seja de produção, verificando se os limites para as condições de parada são ativados conforme o esperado durante o teste e se há observabilidade em vigor para identificar uma exceção, em vez de testar diretamente em produção. 

     Ao executar testes de injeção de falhas, verifique se todas as partes responsáveis estão bem informadas. Comunique-se com as equipes adequadas, como equipes de operações, equipes de confiabilidade do serviço e atendimento ao cliente, para avisá-las sobre quando os testes serão realizados e o que esperar. Ofereça a essas equipes ferramentas de comunicação para que informem os responsáveis pela execução do teste caso percebam algum efeito adverso. 

     Você deve restaurar a workload e seus sistemas subjacentes de volta para o estado íntegro original. Normalmente, o design resiliente da workload vai se autorrestaurar. No entanto, alguns designs de falhas ou testes malsucedidos podem deixar a workload em um estado de falha inesperado. Ao final do teste, você deverá estar ciente disso e restaurar a workload e os sistemas. Com o AWS FIS, você pode definir uma configuração de reversão (também chamada de ação posterior) nos parâmetros de ação. Uma ação posterior restaura o destino para o estado em que estava antes da execução da ação. Independentemente de serem automatizadas (como as que usam o AWS FIS) ou manuais, essas ações posteriores devem fazer parte de um playbook que descreve como detectar e lidar com falhas. 
  +  Verifique a hipótese. 

    [Princípios da engenharia do caos](https://principlesofchaos.org/) oferecem a seguinte orientação sobre como verificar o estado estável de sua workload: 

    Concentre-se na saída mensurável de um sistema, em vez de atributos internos do sistema. As medições dessa saída durante um curto período constituem um proxy do estado estável do sistema. A throughput total do sistema, as taxas de erros e os percentis de latência podem ser métricas de interesse que representam o comportamento do estado estável. Ao focar em padrões de comportamento sistêmicos durante os testes, a engenharia de caos verifica se o sistema de fato funciona em vez de tentar validar como ele funciona.

     Nos dois exemplos anteriores, nós incluímos as métricas de estado estável de menos de 0,01% de aumento na quantidade de erros no servidor (5xx) e menos de um minuto de erros de leitura ou gravação de banco de dados. 

     Os erros 5xx são uma boa métrica, pois são consequência do modo de falha que um cliente da workload vai vivenciar diretamente. A medição dos erros do banco de dados é boa como consequência direta da falha, mas também deve ser complementada com uma medição de impacto para o cliente, como solicitações malsucedidas ou erros apresentados ao cliente. Além disso, inclua um monitor sintético (também conhecido como canário de usuário) em todas as APIs ou URIs acessadas pelo cliente da workload. 
  +  Melhore o design da workload para agregar resiliência. 

     Se o estado estável não tiver sido mantido, investigue como o design da workload pode ser melhorado para mitigar a falha, aplicando as práticas recomendadas do [pilar Confiabilidade do AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Orientação e recursos adicionais podem ser encontrados na [AWS Builder’s Library](https://aws.amazon.com/builders-library/), que contém artigos sobre como [melhorar as verificações de integridade](https://aws.amazon.com/builders-library/implementing-health-checks/) ou [implantar repetições sem recuo no código de sua aplicação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), entre outros. 

     Depois de implementar essas mudanças, execute o teste novamente (mostrado pela linha pontilhada no flywheel de engenharia de caos) para determinar a eficácia. Se a etapa de verificação indicar que a hipótese é verdadeira, a workload estará em estado estável e o ciclo continuará. 
+  Execute testes regularmente. 

   Um teste de caos é um ciclo, e os testes devem ser realizados regularmente como parte da engenharia de caos. Depois que uma workload cumprir a hipótese do teste, o teste deverá ser automatizado para ser executado continuamente como parte de regressão do pipeline de CI/CD. Para saber como fazer isso, consulte este blog sobre [como executar testes do AWS FIS usando o AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/). Este laboratório sobre [testes recorrentes do AWS FIS em um pipeline de CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) permite que você trabalhe de maneira prática. 

   Os testes de injeção de falhas também fazem parte dos dias de jogo (consulte [REL12-BP06 Realizar dias de jogo regularmente](rel_testing_resiliency_game_days_resiliency.md)). Os dias de jogo simulam uma falha ou um evento para verificar sistemas, processos e respostas das equipes. O objetivo é realmente executar as ações que a equipe executaria como se um evento excepcional acontecesse. 
+  Capture e armazene os resultados do teste. 

  Os resultados da injeção de falhas devem ser capturados e persistidos. Inclua todos os dados necessários (como tempo, workload e condições) para poder analisar os resultados e as tendências do teste posteriormente. Exemplos de resultados podem incluir capturas de tela de painéis, despejos em CSV do banco de dados da métrica ou um registro manual dos eventos e das observações do teste. [O registro do teste em log com o AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) pode fazer parte dessa captura de dados.

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL08-BP03 Integrar testes de resiliência como parte da sua implantação](rel_tracking_change_management_resiliency_testing.md) 
+  [REL13-BP03 Testar a implementação da recuperação de desastres para validá-la](rel_planning_for_recovery_dr_tested.md) 

 **Documentos relacionados:** 
+  [O que é o AWS Fault Injection Service?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 
+  [O que é o AWS Resilience Hub?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 
+  [Princípios da engenharia do caos](https://principlesofchaos.org/) 
+  [Engenharia de caos: planejando seu primeiro teste](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde) 
+  [Engenharia de resiliência: aprendendo a aceitar falhas](https://queue.acm.org/detail.cfm?id=2371297) 
+  [Histórias sobre engenharia de caos](https://github.com/ldomb/ChaosEngineeringPublicStories) 
+  [Evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) 
+  [Implantação canário para testes de caos](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) 

 **Vídeos relacionados:** 
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering (ARC316) (AWS re:Invent 2020: teste de resiliência usando engenharia de caos)](https://www.youtube.com/watch?v=OlobVYPkxgg) 
+  [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1) (AWS re:Invent 2019: melhoria da resiliência com engenharia de caos)](https://youtu.be/ztiPjey2rfY) 
+  [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301) (AWS re:Invent 2019: execução da engenharia de caos em um universo de tecnologia sem servidor)](https://www.youtube.com/watch?v=vbyjpMeYitA) 

 **Exemplos relacionados:** 
+  [Laboratório do Well-Architected: nível 300: testes de resiliência do Amazon EC2, Amazon RDS e Amazon S3](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/) 
+  [Laboratório Engenharia de caos na AWS](https://chaos-engineering.workshop.aws/en/) 
+  [Laboratório Aplicações resilientes e bem-arquitetadas com engenharia de caos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US) 
+  [Laboratório Caos em tecnologia sem servidor](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless) 
+  [Laboratório Mensurar e aumentar a resiliência de sua aplicação com o AWS Resilience Hub](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab) 

 ** Ferramentas relacionadas: ** 
+  [AWS Fault Injection Service](https://aws.amazon.com/fis/) 
+ AWS Marketplace: [plataforma de engenharia de caos Gremlin](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney) 
+  [Chaos Toolkit](https://chaostoolkit.org/) 
+  [Chaos Mesh](https://chaos-mesh.org/) 
+  [Litmus](https://litmuschaos.io/) 

# REL12-BP06 Realizar dias de jogo regularmente
<a name="rel_testing_resiliency_game_days_resiliency"></a>

 Use os dias de jogo para praticar regularmente seus procedimentos de resposta a eventos e falhas o mais próximo possível da produção (inclusive em ambientes de produção) e com as pessoas que estarão envolvidas nos cenários de falha reais. Os dias de jogo aplicam medidas para garantir que os eventos de produção não afetem os usuários. 

 Os dias de jogo simulam uma falha ou evento para testar sistemas, processos e respostas das equipes. O objetivo é realmente executar as ações que a equipe executaria como se um evento excepcional acontecesse. Isso ajudará a compreender onde as melhorias podem ser feitas e pode ajudar a desenvolver experiência organizacional ao lidar com eventos. Eles devem ser realizados regularmente para que a equipe desenvolva *memória muscular* sobre como responder. 

 Depois que o projeto de resiliência estiver em vigor e tiver sido testado em ambientes que não sejam de produção, um dia de jogo será a maneira de garantir que tudo funcione conforme o planejado na produção. Um dia de jogo, especialmente o primeiro, é uma atividade de "todos os funcionários" em que engenheiros e operações são informados quando isso acontecerá e o que ocorrerá. Há runbooks disponíveis. Os eventos simulados são executados, incluindo possíveis eventos de falha, nos sistemas de produção da maneira prescrita, e o impacto é avaliado. Se todos os sistemas operarem conforme projetado, a detecção e a recuperação automática ocorrerão com pouco ou nenhum impacto. No entanto, se houver impacto negativo, o teste será revertido e os problemas da workload serão corrigidos manualmente, se necessário (usando o runbook). Como os dias de jogos ocorrem na produção, todas as precauções devem ser tomadas para garantir que não haja impacto na disponibilidade dos clientes. 

 **Antipadrões comuns:** 
+  Documentar seus procedimentos, mas nunca os praticar. 
+  Não incluir os tomadores de decisão de negócios nos exercícios de teste. 

 **Benefícios do estabelecimento desta prática recomendada:** A realização frequente dos dias de jogo garante que toda a equipe siga e valide as políticas e os procedimentos apropriados quando ocorrer um incidente real. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Programe os dias de jogo para praticar regularmente os runbooks e os manuais. Os dias de jogo devem incluir todas as pessoas envolvidas em um evento de produção: proprietário da empresa, equipe de desenvolvimento, equipe operacional e equipes de resposta a incidentes. 
  +  Execute os testes de carga ou de performance e, em seguida, execute a injeção de falha. 
  +  Procure por anomalias nos runbooks e oportunidades de praticar os playbooks. 
    +  Se você se desviar dos runbooks, refine-os ou corrija o comportamento. Se você praticar o playbook, identifique o runbook que deveria ter sido usado ou crie um novo. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [O que é o AWS GameDay?](https://aws.amazon.com/gameday/) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY) 

   **Exemplos relacionados:** 
+  [Laboratórios do AWS Well-Architected: testes de resiliência](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/) 

# CONFIABILIDADE 13. Como planejar a recuperação de desastres (DR)?
<a name="rel-13"></a>

Implementar backups e componentes redundantes de carga de trabalho é o ponto de partida da sua estratégia de DR. [RTO e RPO são os seus objetivos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) para a restauração da workload. Defina-os de acordo com suas necessidades de negócios. Implemente uma estratégia para atender a esses objetivos, considerando os locais e a função dos recursos e dos dados da carga de trabalho. A probabilidade de interrupção e o custo de recuperação também são fatores principais que ajudam a determinar o valor empresarial de fornecer a recuperação de desastres para uma workload.

**Topics**
+ [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testar a implementação da recuperação de desastres para validá-la](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Gerenciar o desvio de configuração para o local ou a região de DR](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Automatizar a recuperação](rel_planning_for_recovery_auto_recovery.md)

# REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados
<a name="rel_planning_for_recovery_objective_defined_recovery"></a>

 A carga de trabalho tem um Recovery Time Objective (RTO – Objetivo do tempo de recuperação) e um Recovery Point Objective (RPO – Objetivo do ponto de recuperação). 

 *Recovery Time Objective (RTO – Objetivo do tempo de recuperação)* é o atraso máximo aceitável entre a interrupção do serviço e sua restauração. Isso determina o que é considerado uma janela de tempo aceitável quando o serviço está indisponível. 

 *Recovery Point Objective (RPO – Objetivo do ponto de recuperação)*  é o tempo máximo 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. 

 Os valores de RTO e RPO são considerações importantes ao selecionar uma estratégia de recuperação de desastres (DR) apropriada para a workload. Esses objetivos são determinados pelo negócio e, em seguida, usados ​​pelas equipes técnicas para selecionar e implementar uma estratégia de DR. 

 **Resultado desejado:**  

 Cada workload tem um RTO e um RPO atribuídos, definidos com base no impacto empresarial. A workload é atribuída a uma camada predefinida com um RTO e um RPO associados, estabelecendo a disponibilidade do serviço e a perda aceitável de dados. Se isso não for possível, poderá ser atribuído sob medida por workload com a intenção de criar camadas posteriormente. O RTO e o RPO são usados ​​como uma das principais considerações para a seleção da implementação de uma estratégia de recuperação de desastres para a workload. São considerações adicionais na escolha de uma estratégia de DR as restrições de custo, as dependências da workload e os requisitos operacionais. 

 Para o RTO, compreenda o impacto com base na duração de uma interrupção. É linear ou há implicações não lineares? (Por exemplo, após quatro horas, você desliga uma linha de produção até o início do próximo turno). 

 Uma matriz de recuperação de desastres, como a seguinte, pode ajudar você a compreender como a criticidade da workload se relaciona com os objetivos de recuperação. (Observe que os valores reais dos eixos X e Y devem ser personalizados de acordo com as necessidades da sua organização). 

![\[Gráfico mostrando a matriz de recuperação de desastres\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/disaster-recovery-matrix.png)


 **Antipadrões comuns:** 
+  Objetivos de recuperação não definidos. 
+  Seleção de objetivos de recuperação arbitrários. 
+  Seleção de objetivos de recuperação que são muito permissivos e não atendem aos objetivos de negócios. 
+  Não compreender o impacto do tempo de inatividade e da perda de dados. 
+  Seleção de objetivos de recuperação irreais, como nenhum tempo para recuperação e nenhuma perda de dados, que podem não ser alcançáveis ​​para a configuração da workload. 
+  Seleção de objetivos de recuperação mais rigorosos do que os objetivos de negócios reais. Isso força implementações de DR mais caras e complicadas do que as necessidades da workload. 
+  Seleção de objetivos de recuperação incompatíveis com os da workload dependente. 
+  Os objetivos de recuperação não consideram os requisitos regulamentares de conformidade. 
+  RTO e RPO definidos para uma workload, mas nunca testados. 

 **Benefícios do estabelecimento dessa prática recomendada:** Os objetivos de recuperação referentes a tempo e perda de dados são necessários para orientar a implementação da DR. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Para a workload, você deve compreender o impacto do tempo de inatividade e da perda de dados em seus negócios. O impacto geralmente aumenta com maior tempo de inatividade ou perda de dados, mas a forma desse crescimento pode diferir com base no tipo de workload. Por exemplo, pode ser que você consiga tolerar o tempo de inatividade por até uma hora com pouco impacto, mas depois disso o impacto aumenta rapidamente. O impacto nos negócios se manifesta de diversas formas, incluindo custo monetário (como perda de receita), confiança do cliente (e impacto na reputação), problemas operacionais (como folha de pagamento ausente ou diminuição na produtividade) e risco regulatório. Use as etapas a seguir para compreender esses impactos e defina o RTO e o RPO para sua workload. 

 **Etapas da implementação** 

1.  Determine as partes interessadas do negócio para a workload e interaja com eles para implementar essas etapas. Os objetivos de recuperação para uma workload são uma decisão de negócios. As equipes técnicas trabalham com as partes interessadas do negócio para usar esses objetivos para selecionar uma estratégia de DR. 
**nota**  
Para as etapas 2 e 3, você pode usar o [Planilha de implementação](#implementation-worksheet).

1.  Reúna as informações necessárias para tomar uma decisão respondendo às perguntas abaixo. 

1.  Você tem categorias ou níveis de criticidade para o impacto da workload na sua organização? 

   1.  Se sim, atribua esta workload a uma categoria 

   1.  Se não, estabeleça estas categorias. Crie cinco ou menos categorias e refine o intervalo do seu objetivo de tempo de recuperação para cada uma delas. Os exemplos de categorias incluem: crítica, alta, média, baixa. Para entender como uma workloads é mapeada para uma categoria, considere se ela é de missão crítica, importante para os negócios ou não comercial. 

   1.  Defina o RTO e o RPO da workload com base na categoria. Sempre escolha uma categoria mais restrita (RTO e RPO mais baixos) do que os valores brutos calculados no começo desta etapa. Se isso resultar em uma mudança de valor inadequadamente grande, considere a criação de uma nova categoria. 

1.  Com base nessas respostas, atribua valores de RTO e RPO à workload. Isso pode ser feito diretamente ou atribuindo a workload a uma camada de serviço predefinida. 

1.  Documente o plano de recuperação de desastres (DRP) para esta workload, que faz parte [do plano de continuidade de negócios (BCP) da sua organização](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html), em um local acessível à equipe de workload e às partes interessadas 

   1.  Registre o RTO, o RPO e as informações usadas para determinar esses valores. Inclua a estratégia usada para avaliar o impacto da workload nos negócios. 

   1.  Registre outras métricas, além do RTO e do RPO que você está acompanhando ou planeja acompanhar, para os objetivos de recuperação de desastres 

   1.  Você adicionará detalhes da sua estratégia de DR e runbook a este plano ao criá-los. 

1.  Ao pesquisar a criticidade da workload em uma matriz, como a da figura 15, você pode começar a estabelecer camadas predefinidas de serviço estabelecidos para sua organização. 

1.  Após implementar uma estratégia de DR (ou uma prova de conceito para uma estratégia de DR) conforme [REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md), teste a estratégia para determinar a capacidade de tempo de recuperação (RTC) e a capacidade de ponto de recuperação (RPC) reais da workload. Se elas não atenderem aos objetivos de recuperação de destino, trabalhe com as partes interessadas do negócio para ajustar esses objetivos ou faça alterações na estratégia de DR para atingir os objetivos de destino. 

 **Perguntas principais** 

1.  Qual é o tempo máximo que a workload pode ficar inativa antes que ocorra um impacto grave nos negócios? 

   1.  Determine o custo monetário (impacto financeiro direto) para o negócio por minuto se a workload for interrompida. 

   1.  Considere que o impacto nem sempre é linear. O impacto pode ser limitado no início e aumentar rapidamente após um ponto crítico. 

1.  Qual é a quantidade máxima de dados que podem ser perdidos antes que ocorra um impacto severo nos negócios? 

   1.  Considere esse valor para seu armazenamento de dados mais crítico. Identifique a respectiva criticidade para outros armazenamentos de dados. 

   1.  Os dados de workload podem ser recriados em caso de perda? Se isso for operacionalmente mais fácil do que fazer backup e restauração, escolha o RPO com base na criticidade dos dados de origem usados ​​para recriar os dados da workload. 

1.  Quais são os objetivos de recuperação e as expectativas de disponibilidade das workloads das quais este depende (downstream) ou as workloads que dependem deste (upstream)? 

   1.  Escolha objetivos de recuperação que permitam que essa workload atenda aos requisitos das dependências upstream. 

   1.  Escolha objetivos de recuperação que possam ser alcançados com base nos recursos de recuperação das dependências downstream. Dependências downstream não críticas (aquelas que podem ser “contornadas”) podem ser excluídas. Ou trabalhe com dependências críticas downstream para melhorar os recursos de recuperação quando necessário. 

 **Perguntas adicionais** 

 Considere estas perguntas e como elas podem se aplicar a essa workload: 

1.  Você tem RTO e RPO diferentes dependendo do tipo de interrupção (região versus AZ etc.)? 

1.  Existe um momento específico (sazonalidade, eventos de vendas, lançamentos de produtos) em que seu RTO/RPO pode mudar? Se sim, quais são a medição e o limite de tempo diferentes? 

1.  Quantos clientes serão afetados se a workload for interrompida? 

1.  Qual será o impacto na reputação se a workload for interrompida? 

1.  Quais outros impactos operacionais poderão ocorrer se a workload for interrompida? Por exemplo, impacto na produtividade do funcionário se os sistemas de e-mail não estiverem disponíveis ou se os sistemas de folha de pagamento não puderem enviar transações. 

1.  Como o RTO e o RPO da workload se alinham à estratégia de DR da linha empresarial e organizacional? 

1.  Há obrigações contratuais internas para a prestação de um serviço? Há penalidades por não cumpri-las? 

1.  Quais são as restrições regulatórias ou de conformidade com os dados? 

## Planilha de implementação
<a name="implementation-worksheet"></a>

 Você pode usar esta planilha para as etapas 2 e 3 de implementação. É possível ajustar esta planilha para atender às suas necessidades específicas, como adicionar perguntas. 

<a name="worksheet"></a>![\[Planilha\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/worksheet.png)


 **Nível de esforço para o plano de implementação: **Baixo 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL09-BP04 Realizar a recuperação periódica dos dados para verificar a integridade e os processos de backup](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md) 
+ [REL13-BP03 Testar a implementação da recuperação de desastres para validá-la](rel_planning_for_recovery_dr_tested.md) 

 **Documentos relacionados:** 
+  [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [Gerenciamento de políticas de resiliência com o AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html) 
+  [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
+  [Recuperação de desastres de workloads na AWS](https://www.youtube.com/watch?v=cJZw5mrxryA) 

# REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação
<a name="rel_planning_for_recovery_disaster_recovery"></a>

Defina uma estratégia de recuperação de desastres (DR) que cumpra os objetivos de recuperação da workload. Escolha uma estratégia como backup e restauração, standby (ativo/passivo) ou ativo/ativo.

 **Resultado desejado:** há uma estratégia de DR definida e implementada para cada workload, permitindo que ela atinja os objetivos de DR. As estratégias de DR entre workloads fazem uso de padrões reutilizáveis ​​(como as estratégias descritas anteriormente). 

 **Antipadrões comuns:** 
+  Implementar procedimentos de recuperação inconsistentes para workloads com objetivos de DR semelhantes. 
+  Deixar que a estratégia de DR seja implementada ad hoc quando ocorrer um desastre. 
+  Não ter um plano para a recuperação de desastres. 
+  Depender das operações do ambiente de gerenciamento durante a recuperação. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  O uso de estratégias de recuperação definidas permite que você adote ferramentas comuns e procedimentos de teste. 
+  Usar estratégias de recuperação definidas melhora o compartilhamento de conhecimento entre as equipes e a implementação da DR nas workloads que possuem. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto. Sem uma estratégia de DR planejada, implementada e testada, é improvável que você cumpra os objetivos de recuperação em caso de desastre. 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Uma estratégia de DR depende da capacidade de manter a workload em um site de recuperação se o local primário não puder executar a workload. Os objetivos de recuperação mais comuns são o RTO e o RPO, conforme discutido em [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md). 

 Uma estratégia de DR em várias zonas de disponibilidade (AZs) em uma única Região da AWS pode fornecer mitigação contra eventos de desastre, como incêndios, inundações e grandes interrupções de energia. Se for um requisito implementar proteção contra um evento improvável que impeça a execução da workload em determinada Região da AWS, você poderá optar por uma estratégia de DR que use várias regiões. 

 Ao arquitetar uma estratégia de DR em várias regiões, você deve escolher uma das estratégias a seguir. Elas estão listadas em ordem crescente de custo e complexidade e em ordem decrescente de RTO e RPO. *Região de recuperação* refere-se a uma Região da AWS diferente da primária usada para a workload. 

![\[Diagrama mostrando estratégias de DR\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/disaster-recovery-strategies.png)

+  **Backup e restauração** (RPO em horas, RTO em 24 horas ou menos): faça backup de seus dados e aplicações na região de recuperação. O uso de backups automatizados ou contínuos permitirá a recuperação a um ponto anterior no tempo, podendo reduzir o RPO para até cinco minutos em alguns casos. Em caso de desastre, você implantará a infraestrutura (usando a infraestrutura como código para reduzir o RTO), implantará o código e restaurará os dados salvos para se recuperar de um desastre na região de recuperação. 
+  **Luz piloto** (RPO em minutos, RTO em dezenas de minutos): provisione uma cópia da infraestrutura de workload principal na região de recuperação. Replique seus dados na região de recuperação e crie backups deles lá. 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 aplicações ou computação com tecnologia sem servidor, não são implantados. Porém, podem ser criados com a configuração e o código da aplicação necessários. 
+  **Standby passivo** (RPO em segundos, RTO em minutos): mantenha uma versão reduzida, mas totalmente funcional, da workload sempre em execução na região de recuperação. Os sistemas críticos para os negócios são totalmente duplicados e estão sempre ativados, mas com uma frota reduzida. Os dados são replicados e vivem na região de recuperação. Quando chega o momento da recuperação, o sistema é dimensionado rapidamente para processar a carga de produção. Quanto mais a escala do standby passivo for aumentada verticalmente, menor será a dependência do RTO e do ambiente de gerenciamento. Quando totalmente dimensionado, isso é conhecido como *standby a quente*. 
+  **Ativo/ativo de várias regiões (multissite)** (RPO próximo a zero, RTO potencialmente zero): a workload é implantada em várias Regiões da AWS e processa ativamente o tráfego delas. Essa estratégia exige que você sincronize os dados entre regiões. Deve-se evitar ou lidar com possíveis conflitos causados ​​por gravações no mesmo registro em duas réplicas regionais diferentes, o que pode ser complexo. A replicação de dados é útil para a sincronização de dados e protegerá você contra alguns tipos de desastre, mas não contra corrupção ou destruição de dados, a menos que sua solução também inclua opções para recuperação a um ponto anterior no tempo. 

**nota**  
 Às vezes, a diferença entre luz-piloto e standby passivo pode ser difícil de entender. Ambos incluem um ambiente na região de recuperação com cópias dos ativos da região primária. A diferença é que a luz-piloto não pode processar solicitações sem primeiro realizar uma ação adicional, enquanto o standby passivo pode processar o tráfego (em níveis de capacidade reduzidos) imediatamente. A luz piloto exigirá que você ative os servidores, possivelmente implante infraestrutura adicional (não essencial) e aumente a escala verticalmente. Já o standby passivo exige apenas que você aumente a escala verticalmente (tudo já está implantado e em execução). Escolha entre elas com base nas suas necessidades de RTO e RPO.   
 Quando o custo é uma preocupação e você deseja alcançar objetivos de RPO e RTO semelhantes, conforme definido na estratégia de standby passivo, é possível considerar soluções nativas da nuvem, como Recuperação de desastres do AWS Elastic, que adota a abordagem de luz piloto e oferece metas de RPO e RTO aprimoradas. 

 **Etapas da implementação** 

1.  **Determine uma estratégia de DR que satisfaça os requisitos de recuperação para essa workload.** 

 Escolher uma estratégia de DR é uma troca entre reduzir o tempo de inatividade e a perda de dados (RTO e RPO) e o custo e a complexidade da sua implementação. Você deve evitar implementar uma estratégia mais rigorosa do que necessário, pois isso resulta em custos desnecessários. 

 Por exemplo, no diagrama a seguir, a empresa determinou o RTO máximo permitido e o orçamento limite da estratégia de restauração de serviço. Considerando os objetivos empresariais, as estratégias de DR luz-piloto e standby passivo satisfarão tanto o RTO quanto os critérios de custo. 

![\[Gráfico mostrando a escolha de uma estratégia de DR com base no RTO e no custo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/choosing-a-dr-strategy.png)


 Para saber mais, consulte [Business Continuity Plan (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html) (Plano de continuidade de negócios (BCP). 

1.  **Revise os padrões de como a estratégia de DR selecionada pode ser implementada.** 

 Essa etapa é para compreender como implementar a estratégia selecionada. As estratégias são explicadas usando as Regiões da AWS como locais primários e de recuperação. No entanto, também é possível optar por usar as zonas de disponibilidade em uma única região como sua estratégia de DR, que faz uso de elementos de várias dessas estratégias. 

 Nas etapas a seguir, é possível aplicar a estratégia para sua workload específica. 

 **Backup e restauração**  

 *Backup e restauração* é a estratégia menos complexa de implementar. Porém, exigirá mais tempo e esforço para restaurar a workload, levando a RTO e RPO mais altos. É uma boa prática sempre fazer backups dos dados e copiá-los para outro local (como outra Região da AWS). 

![\[Diagrama mostrando uma arquitetura de backup e restauração\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/backup-restore-architecture.png)


 Para obter mais detalhes sobre essa estratégia, consulte [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/) (Arquitetura de recuperação de desastres (DR) na AWS, parte II: backup e restauração com recuperação rápida). 

 **Luz piloto** 

 Com a abordagem de *luz-piloto*, você replica os dados da região primária para a região de recuperação. Os principais recursos usados ​​para a infraestrutura da workload são implantados na região de recuperação. No entanto, recursos adicionais e as dependências ainda são necessários para tornar a pilha funcional. Por exemplo, na Figura 20, nenhuma instância de computação é implantada. 

![\[Diagrama mostrando uma arquitetura de luz-piloto\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/pilot-light-architecture.png)


 Para obter mais detalhes sobre essa estratégia, consulte [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz-piloto e standby passivo). 

 **Modo de espera passivo** 

 A abordagem de *standby passivo* envolve garantir que haja uma cópia com escala reduzida verticalmente, 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. Se a região de recuperação estiver implantada com sua capacidade total, isso é conhecido como *standby a quente*. 

![\[Diagrama mostrando a Figura 21: uma arquitetura de standby passivo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/warm-standby-architecture.png)


 O uso de standby passivo ou luz-piloto requer que a escala dos recursos seja aumentada verticalmente na região de recuperação. Para verificar se a capacidade está disponível quando necessário, considere o uso de [reservas de capacidade](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) para instâncias do EC2. Se você usar o AWS Lambda, a [simultaneidade provisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) poderá fornecer ambientes de execução para que eles sejam preparados para responder imediatamente às invocações da função. 

 Para obter mais detalhes sobre essa estratégia, consulte [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz-piloto e standby passivo). 

 **Multissite ativo/ativo** 

 É possível executar a workload simultaneamente em várias regiões como parte de uma estratégia de *multissite ativo/ativo*. O multissite ativo-ativo atende ao tráfego de todas as regiões onde está implantado. Os clientes podem selecionar essa estratégia por outros motivos, além da DR. Ela pode ser usada para aumentar a disponibilidade ou ao implantar uma workload para um público global (a fim de aproximar o endpoint dos usuários e/ou implantar pilhas localizadas para o público nessa região). Como uma estratégia de DR, se a workload não for compatível com uma das Regiões da AWS onde está implantada, essa região será evacuada e as regiões restantes serão usadas para manter a disponibilidade. O multissite ativo-ativo é a estratégia de DR mais complexa operacionalmente e deve ser selecionada apenas quando os requisitos empresariais exigirem. 

![\[Diagrama mostrando uma arquitetura de multissite ativo-ativo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/multi-site-active-active-architecture.png)


 

 Para obter mais detalhes sobre essa estratégia, consulte [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/) (Arquitetura de recuperação de desastres (DR) na AWS, parte IV: multissite ativo/ativo). 

 **Recuperação de desastres do AWS Elastic** 

 Se você estiver considerando a estratégia de luz-piloto ou de standby passivo para a recuperação de desastres, o Recuperação de desastres do AWS Elastic poderia fornecer uma abordagem alternativa com benefícios melhorados. O Elastic Disaster Recovery pode oferecer uma meta de RPO e RTO semelhante à do standby passivo, mas mantém a abordagem de baixo custo da luz-piloto. O Elastic Disaster Recovery replica os dados da região primária para a região de recuperação, usando a proteção contínua de dados para alcançar um RPO medido em segundos e um RTO que pode ser medido em minutos. Somente os recursos necessários para replicar os dados são implantados na região de recuperação, o que mantém os custos baixos, semelhante à estratégia de luz-piloto. Ao usar o Elastic Disaster Recovery, o serviço coordena e orquestra a recuperação de recursos de computação quando iniciado como parte de um failover ou de uma simulação. 

![\[Diagrama da arquitetura descrevendo como o Recuperação de desastres do AWS Elastic opera.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/drs-architecture.png)


 

 **Práticas adicionais para proteção de dados** 

 Com todas as estratégias, você também deve atenuar um desastre de dados. A replicação contínua de dados protege você contra alguns tipos de desastre, mas não contra corrupção ou destruição de dados, a menos que sua solução também inclua o versionamento de dados armazenados ou opções para recuperação a um ponto anterior no tempo. Você também deve fazer backup dos dados replicados no local de recuperação para criar backups pontuais além das réplicas. 

 **O uso de várias zonas de disponibilidade (AZs) em uma única Região da AWS** 

 Ao utilizar várias AZs em uma única região, a implementação de DR usa vários elementos das estratégias acima. Primeiro, você deve criar uma arquitetura de alta disponibilidade (HA), usando várias AZs, conforme mostrado na Figura 23. Essa arquitetura usa uma abordagem multissite ativo/ativo, já que as [instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) e o [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) tem recursos implantados em várias AZs, processando solicitações ativamente. A arquitetura também demonstra o standby a quente, no qual, caso a instância primária do [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) falhe (ou a própria AZ falhe), a instância de standby será promovida a primária. 

![\[Diagrama mostrando a Figura 24: Arquitetura Multi-AZ\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/multi-az-architecture2.png)


 Além da arquitetura de alta disponibilidade, você precisa adicionar backups de todos os dados necessários para executar a workload. Isso é especialmente importante para dados restritos a uma única zona, como [volumes do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) ou [clusters do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Se uma AZ falhar, você precisará restaurar esses dados para outra AZ. Sempre que possível, você também deve copiar backups de dados para outra Região da AWS, como uma camada adicional de proteção. 

 Uma abordagem alternativa menos comum para uma única região, a DR Multi-AZ está ilustrada nesta publicação de blog, [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) (Criar aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única). Aqui, a estratégia é manter o máximo de isolamento possível entre as AZs, assim como as regiões operam. Ao usar esta estratégia alternativa, você pode escolher uma abordagem ativa/ativa ou ativa/passiva. 

**nota**  
Algumas workloads têm requisitos regulamentares de residência de dados. Se isso se aplicar à sua workload em uma localidade que atualmente tem apenas uma Região da AWS, a multirregião não atenderá às suas necessidades empresariais. As estratégias Multi-AZ fornecem boa proteção contra a maioria dos desastres. 

1.  **Avalie os recursos da workload e qual será sua configuração na região de recuperação antes do failover (durante a operação normal).** 

 Para recursos de infraestrutura e da AWS, use a infraestrutura como código, como o [AWS CloudFormation](https://aws.amazon.com/cloudformation), ou ferramentas de terceiros, como o Hashicorp Terraform. Para implantar em várias contas e regiões com uma única operação, você pode usar o [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Para estratégias multissite ativo-ativo e standby a quente, a infraestrutura implantada na região de recuperação tem os mesmos recursos que a região primária. Para as estratégias de luz-piloto e standby passivo, a infraestrutura implantada exigirá ações adicionais para ficar pronta para produção. Usando [parâmetros](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) e [lógica condicional](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) do CloudFormation, é possível controlar se uma pilha implantada está ativa ou em espera com [um único modelo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). Ao usar o Elastic Disaster Recovery, o serviço vai replicar e orquestrar a restauração de configurações da aplicação e os recursos de computação. 

 Todas as estratégias de DR exigem que seja feito backup das fontes de dados na Região da AWS e, então, esses backups são copiados para a região de recuperação. O [AWS Backup](https://aws.amazon.com/backup/) fornece uma visão centralizada em que é possível configurar, programar e monitorar backups para esses recursos. Para luz-piloto, standby passivo e multissite ativo-ativo, você também deve replicar dados da região primária para recursos de dados na região de recuperação, como instâncias de banco de dados do [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) ou tabelas do [Amazon DynamoDB](https://aws.amazon.com/dynamodb). Esses recursos de dados estão ativos e prontos para atender a solicitações na região de recuperação. 

 Para saber mais sobre como os serviços da AWS operam entre regiões, consulte essa série de blog em [Creating a Multi-Region Application with AWS Services](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) (Criar uma aplicação de várias regiões com os serviços da AWS). 

1.  **Determine e implemente como deixar sua região de recuperação pronta para failover quando necessário (durante um evento de desastre).** 

 Para multissite ativo-ativo, failover significa evacuar uma região e confiar nas regiões ativas restantes. No geral, essas regiões estão prontas para aceitar tráfego. Para as estratégias de luz-piloto e standby passivo, as ações de recuperação precisarão implantar os recursos ausentes, como as instâncias do EC2 na Figura 20, além de quaisquer outros recursos ausentes. 

 Para todas as estratégias acima, pode ser necessário promover instâncias somente leitura de bancos de dados para se tornar a instância primária de leitura/gravação. 

 Para backup e restauração, a restauração de dados do backup cria recursos para esses dados, como volumes do EBS, instâncias de banco de dados do RDS e tabelas do DynamoDB. Você também precisa restaurar a infraestrutura e implantar o código. É possível usar o AWS Backup para restaurar dados na região de recuperação. Perceber [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md) para obter mais detalhes. A reconstrução da infraestrutura inclui a criação de recursos como instâncias do EC2, além da [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), de sub-redes e dos grupos de segurança necessários. É possível automatizar grande parte do processo de restauração. Para saber como, consulte [esta publicação do blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/). 

1.  **Determine e implemente como redirecionar o tráfego para failover quando necessário (durante um evento de desastre).** 

 Essa operação de failover pode ser iniciada de forma manual ou automática. O failover iniciado automaticamente com base em verificações de integridade ou alarmes deve ser usado com cautela, pois um failover desnecessário (alarme falso) resulta em custos como indisponibilidade e perda de dados. Portanto, geralmente é usado o failover iniciado manualmente. Nesse caso, você ainda deve automatizar as etapas para failover, para que a inicialização manual seja como apertar um botão. 

 Há várias opções de gerenciamento de tráfego a serem consideradas ao usar os serviços da Regiões da AWS. Uma opção é usar o [Amazon Route 53](https://aws.amazon.com/route53). Ao usar o Amazon Route 53, você pode associar vários endpoints de IP em uma ou mais Regiões da AWS a um nome de domínio do Route 53. Para implementar um failover iniciado manualmente, é possível usar o [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/), o que fornece uma API de plano de dados altamente disponível para rotear novamente o tráfego para a região de recuperação. Ao implementar o failover, use as operações do plano de dados e evite as do ambiente de gerenciamento, conforme descrito em [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md). 

 Para saber mais sobre essa e outras opções, consulte [esta seção do whitepaper de recuperação de desastres](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light). 

1.  **Projete um plano de como será feito failback da workload.** 

 Failback é quando você retorna a operação de workload para a região primária, após o término de um evento de desastre. O provisionamento de infraestrutura e código para a região primária geralmente segue as mesmas etapas que foram usadas inicialmente, contando com a infraestrutura como código e pipelines de implantação de código. O desafio com o failback é restaurar os armazenamentos de dados e garantir sua consistência com a região de recuperação em operação. 

 No estado de failover, os bancos de dados na região de recuperação estão ativos e têm dados atualizados. O objetivo é ressincronizar da região de recuperação para a região primária, garantindo que ela esteja atualizada. 

 Alguns serviços da AWS farão isso automaticamente. Se você usar [tabelas globais do Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), mesmo que a tabela na região primária tenha ficado indisponível, quando ela voltar a ficar online, o DynamoDB retomará a propagação das gravações pendentes. Se você usar o [banco de dados global do Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) e o [failover planejado e gerenciado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), a topologia da replicação existente do banco de dados global do Aurora será mantida. Portanto, a antiga instância de leitura/gravação na região primária se tornará uma réplica e receberá atualizações da região de recuperação. 

 Em casos nos quais isso não seja automático, você precisará restabelecer o banco de dados na região primária como uma réplica do banco de dados na região de recuperação. Em muitos casos, isso envolverá a exclusão do banco de dados primário antigo e a criação de outras réplicas. Por exemplo, para obter instruções de como fazer isso com o banco de dados global do Amazon Aurora presumindo um failover *não planejado*, consulte este laboratório: [Fail Back a Global Database](https://awsauroralabsmy.com/global/failback/) (Executar failback em um banco de dados global). 

 Após um failover, se você puder continuar a execução na região de recuperação, considere torná-la a nova região primária. Você ainda seguiria todas as etapas acima para transformar a antiga região primária em uma região de recuperação. Algumas organizações fazem uma alternância programada, trocando as regiões primárias e de recuperação periodicamente (por exemplo, a cada três meses). 

 Todas as etapas necessárias para failover e failback devem ser mantidas em um manual disponível para todos os membros da equipe e que seja revisado periodicamente. 

 Ao usar o Elastic Disaster Recovery, o serviço auxiliará na orquestração e automatização do processo de failback. Para obter mais detalhes, consulte [Performing a failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html) (Como executar failback). 

 **Nível de esforço do plano de implementação:** alto 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md)
+  [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md) 

 **Documentos relacionados:** 
+  [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [Opções de recuperação de desastres na nuvem](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html) 
+  [Crie uma solução de backend ativo-ativo multirregional sem servidor em uma hora](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf) 
+  [Backend multirregional sem servidor: recarregado](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0) 
+  [RDS: replicação de uma réplica de leitura entre regiões](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn) 
+  [Route 53: configuração do failover de DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) 
+  [S3: replicação entre regiões](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) 
+  [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [O que é o Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 
+  [(HashiCorp Terraform: conceitos básicos – AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started) 
+  [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 

 **Vídeos relacionados:** 
+  [Recuperação de desastres de workloads na AWS](https://www.youtube.com/watch?v=cJZw5mrxryA) 
+  [AWS re:Invent 2018: padrões de arquitetura para aplicações ativas/ativas de várias regiões (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
+  [Conceitos básicos do AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as) 

 **Exemplos relacionados:** 
+  [Well-Architected Lab - Disaster Recovery](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - Series of workshops illustrating DR strategies (Laboratório do Well-Architected – Recuperação de desastres: série de workshops ilustrando estratégias de DR) 

# REL13-BP03 Testar a implementação da recuperação de desastres para validá-la
<a name="rel_planning_for_recovery_dr_tested"></a>

Teste regularmente o failover no site de recuperação para verificar se a operação está correta e que o RTO e o RPO sejam cumpridos.

 **Antipadrões comuns:** 
+  Nunca execute failovers na produção. 

 **Benefícios do estabelecimento dessa prática recomendada:** testar regularmente seu plano de recuperação de desastres garante que ele funcione quando necessário e que sua equipe saiba como executar a estratégia. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Um padrão que deve ser evitado é o desenvolvimento de caminhos de recuperação que raramente são executados. Por exemplo, você pode ter um repositório de dados secundário utilizado para consultas somente leitura. Quando você grava em um repositório de dados e o repositório de dados primário falha, pode ser necessário fazer o failover para o repositório de dados secundário. Se você não testar esse failover com frequência, poderá descobrir que suas suposições sobre as capacidades do armazenamento de dados secundário são incorretas. A capacidade do secundário, que talvez tenha sido suficiente quando testado pela última vez, pode não conseguir mais tolerar a carga nesse cenário. Nossa experiência mostrou que a única recuperação de erro que funciona é o caminho que você testa com frequência. É por isso que é melhor ter um pequeno número de caminhos de recuperação. Você pode estabelecer padrões de recuperação e testá-los regularmente. Se você tiver um caminho de recuperação complexo ou crítico, ainda precisará executar regularmente essa falha na produção para garantir o funcionamento desse caminho. No exemplo que acabamos de discutir, você deve realizar o failover para o standby regularmente, não importa a necessidade. 

 **Etapas da implementação** 

1.  Projete suas cargas de trabalho para recuperação. Teste regularmente seus caminhos de recuperação. A computação orientada para a recuperação identifica as características em sistemas que aprimoram a recuperação: isolamento e redundância, capacidade de reverter alterações em todo o sistema, capacidade de monitorar e determinar a integridade, capacidade de realizar diagnósticos, recuperação automatizada, design modular e capacidade de reinicialização. Pratique o caminho da recuperação para verificar se é possível realizá-la no tempo especificado para o estado determinado. Use seus runbooks durante essa recuperação para documentar problemas e encontrar soluções para eles antes do próximo teste. 

1. Para workloads com base no Amazon EC2, use o [Recuperação de desastres do AWS Elastic](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) para implementar e iniciar instâncias de simulação para a estratégia de DR. O Recuperação de desastres do AWS Elastic permite executar simulações com eficiência, o que ajuda você a se preparar para um evento de failover. Também é possível iniciar frequentemente as instâncias usando o Elastic Disaster Recovery para fins de teste e simulação sem redirecionar o tráfego.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 
+  [Recuperação de desastres do AWS Elastic](https://aws.amazon.com/disaster-recovery/) 
+  [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [Recuperação de desastres do AWS Elastic Preparing for Failover](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html) (Recuperação de desastres do AWS Elastic: preparação para failover) 
+  [O projeto de computação orientado por recuperação de Berkeley/Stanford](http://roc.cs.berkeley.edu/) 
+  [What is AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) (O que e o AWS Fault Injection Simulator?) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4) (AWS re:Invent 2018: padrões de arquitetura para aplicações ativas/ativas de várias regiões) 
+  [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS](https://youtu.be/7gNXfo5HZN8) (AWS re:Invent 2019: soluções de backup e restauração e de recuperação de desastres com a AWS) 

 **Exemplos relacionados:** 
+  [Well-Architected Lab - Testing for Resiliency](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/) (Laboratório do Well-Architected: teste de resiliência) 

# REL13-BP04 Gerenciar o desvio de configuração para o local ou a região de DR
<a name="rel_planning_for_recovery_config_drift"></a>

 Certifique-se de que a infraestrutura, os dados e a configuração estejam conforme necessário no local ou na região de DR. Por exemplo, verifique se as AMIs e as cotas de serviço estão atualizadas. 

 O AWS Config monitora e registra continuamente as configurações dos recursos da AWS. Ele pode detectar desvios e acionar o [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) para corrigi-lo e gerar alarmes. O AWS CloudFormation também pode detectar desvios nas pilhas que você implantou. 

 **Antipadrões comuns:** 
+  Falhar ao atualizar os locais de recuperação, ao fazer alterações de configuração ou infraestrutura nos locais primários. 
+  Não considerar possíveis limitações (como diferenças de serviço) nos locais primários e de recuperação. 

 **Benefícios do estabelecimento desta prática recomendada:** Garantir que o ambiente de DR seja consistente com seu ambiente existente para assegurar a recuperação completa. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Garanta que seus pipelines de entrega enviem para seus locais primário e de backup. Os pipelines de entrega para implantação de aplicativos em produção devem ser distribuídos para todos os locais de estratégia de recuperação de desastres especificados, incluindo os ambientes de desenvolvimento e de teste. 
+  Habilite o AWS Config para acompanhar possíveis locais de desvio. Use as regras do AWS Config para criar sistemas que aplicam suas estratégias de recuperação de desastres e geram alertas ao detectar desvios. 
  +  [Correção de recursos não compatíveis do Regras do AWS Config pela AWS](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) 
  +  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  Use o AWS CloudFormation para implantar a infraestrutura. O AWS CloudFormation pode detectar desvios entre as especificações dos modelos do CloudFormation e o que é realmente implantado. 
  +  [AWS CloudFormation: detectar desvios em uma pilha inteira do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS CloudFormation: detectar desvios em uma pilha inteira do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html) 
+  [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [Como faço para implementar uma solução de gerenciamento de configuração de infraestrutura na AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected) 
+  [Correção de recursos não compatíveis do Regras do AWS Config pela AWS](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 

# REL13-BP05 Automatizar a recuperação
<a name="rel_planning_for_recovery_auto_recovery"></a>

 Use ferramentas da AWS ou de terceiros para automatizar a recuperação do sistema e rotear o tráfego para o local ou a região de DR. 

 Com base em verificações de integridade configuradas, os serviços da AWS, como o Elastic Load Balancing e o AWS Auto Scaling, podem distribuir a carga para zonas de disponibilidade íntegras, enquanto outros serviços, como o Amazon Route 53 e o AWS Global Accelerator, podem rotear a carga para Regiões da AWS íntegras. O Amazon Route 53 Application Recovery Controller ajuda a gerenciar e coordenar o failover usando verificações de prontidão e recursos de controle de roteamento. Esses recursos monitoram continuamente a capacidade da aplicação de se recuperar de falhas, permitindo que você controle a recuperação da aplicação em várias Regiões da AWS, zonas de disponibilidade e ambientes on-premises. 

 Para workloads em datacenters físicos ou virtuais existentes ou nuvens privadas, o [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/), disponível por meio do AWS Marketplace, permite que as organizações configurem uma estratégia automatizada de recuperação de desastres para a AWS. O CloudEndure também oferece suporte à recuperação de desastres entre regiões e entre AZs na AWS. 

 **Antipadrões comuns:** 
+  A implementação de failover e failback automatizados idênticos pode causar oscilação quando uma falha ocorre. 

 **Benefícios do estabelecimento dessa prática recomendada:** A recuperação automatizada reduz o tempo de recuperação ao eliminar a oportunidade de erros manuais. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Automatize caminhos de recuperação. No caso de tempos de recuperação curtos, não é possível adotar critério e ação humanos em cenários de alta disponibilidade. O sistema deve recuperar-se automaticamente sob qualquer situação. 
  +  Use o CloudEndure Disaster Recovery para automatizar failover e failback. Ele replica continuamente suas máquinas (incluindo sistema operacional, configuração de estado do sistema, bancos de dados, aplicações e arquivos) em uma área de preparação de baixo custo na Conta da AWS de destino e na região de preferência. Em caso de desastre, você pode instruir o CloudEndure Disaster Recovery a executar automaticamente milhares de máquinas em seu estado totalmente provisionado em minutos. 
    +  [Realizar um failover e failback de recuperação de desastres](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm) 
    +  [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [CloudEndure Disaster Recovery para AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L) 
+  [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 

# Eficiência de performance
<a name="a-performance-efficiency"></a>

O pilar Eficiência de performance inclui 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. Você pode encontrar orientações prescritivas sobre implementação no [Whitepaper sobre pilar de eficiência de performance](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html?ref=wellarchitected-wp).

**Topics**
+ [Seleção de arquitetura](a-selection.md)
+ [Computação e hardware](a-compute-hardware.md)
+ [Gerenciamento de dados](a-data-management.md)
+ [Rede e entrega de conteúdo](a-networking-delivery.md)
+ [Processo e cultura](a-process-culture.md)

# Seleção de arquitetura
<a name="a-selection"></a>

**Topics**
+ [PERFORMANCE 1. Como você seleciona os recursos e a arquitetura de nuvem apropriados para sua workload?](perf-01.md)

# PERFORMANCE 1. Como você seleciona os recursos e a arquitetura de nuvem apropriados para sua workload?
<a name="perf-01"></a>

 A solução ideal para uma workload específica varia e, muitas vezes, as soluções combinam várias abordagens. Workloads do Well-Architected usam várias soluções e permitem diferentes recursos para aprimorar a performance. 

**Topics**
+ [PERF01-BP01 Conheça e compreenda os serviços e recursos de nuvem disponíveis](perf_architecture_understand_cloud_services_and_features.md)
+ [PERF01-BP02 Use a orientação de seu provedor de nuvem ou de um parceiro apropriado para aprender sobre padrões de arquitetura e práticas recomendadas](perf_architecture_guidance_architecture_patterns_best_practices.md)
+ [PERF01-BP03 Inclua o custo nas decisões de arquitetura](perf_architecture_factor_cost_into_architectural_decisions.md)
+ [PERF01-BP04 Avalie como certas trocas (trade-offs) afetam os clientes e a eficiência da arquitetura](perf_architecture_evaluate_trade_offs.md)
+ [PERF01-BP05 Use políticas e arquiteturas de referência](perf_architecture_use_policies_and_reference_architectures.md)
+ [PERF01-BP06 Use testes comparativos para orientar decisões de arquitetura](perf_architecture_use_benchmarking.md)
+ [PERF01-BP07 Use uma abordagem baseada em dados para escolhas de arquitetura](perf_architecture_use_data_driven_approach.md)

# PERF01-BP01 Conheça e compreenda os serviços e recursos de nuvem disponíveis
<a name="perf_architecture_understand_cloud_services_and_features"></a>

 Continue a descobrir e aprender sobre serviços e configurações disponíveis que ajudam a tomar decisões e melhorar a eficiência da performance de suas workloads com base na arquietura. 

 **Antipadrões comuns:** 
+  Você usa a nuvem como um datacenter colocalizado. 
+  Você não moderniza sua aplicação após a migração para a nuvem. 
+  Você só usa um tipo de armazenamento para tudo que precisa ser mantido. 
+  Você usa tipos de instância mais próximos aos padrões atuais, no entanto, maiores, quando necessário. 
+  Você implanta e gerencia tecnologias disponíveis como serviços gerenciados. 

 **Benefícios de estabelecer esta prática recomendada:** Ao pensar em novos serviços e configurações, você poderá melhorar consideravelmente a performance, reduzir custos e otimizar o esforço necessário para manter as workloads. Isso também pode ajudar a acelerar o tempo para valorização dos produtos habilitados para a nuvem. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A AWS lança constantemente novos serviços e recursos que podem melhorar a performance e reduzir o custo das workloads na nuvem. Atualizar-se com relação a esses novos serviços e atributos é crucial para manter a eficácia da performance na nuvem. Modernizar a arquitetura da workload também ajuda a acelerar a produtividade, impulsionar a inovação e ter acesso a mais oportunidades de crescimento. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Faça um inventário do software e da arquitetura usados para serviços relacionados a suas workloads. Decida sobre qual categoria de produtos você quer saber mais. 
+  Explore as ofertas da AWS para identificar e aprender sobre os serviços e as opções de configuração relevantes que podem ajudar você a melhorar a performance e reduzir os custos e a complexidade operacional. 
  +  [Quais são as novidades da AWS?](https://aws.amazon.com/new/) 
  +  [Blog da AWS](https://aws.amazon.com/blogs/) 
  +  [AWS Skill Builder](https://skillbuilder.aws/) 
  +  [Eventos e webinars da AWS](https://aws.amazon.com/events/) 
  +  [Treinamento da AWS and Certifications](https://www.aws.training/) 
  +  [Canal da AWS no Youtube](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg) 
  +  [Workshops da AWS](https://workshops.aws/) 
  +  [Comunidades da AWS](https://aws.amazon.com/events/asean/community-and-events/) 
+  Use ambientes sandbox (sem produção) para aprender e experimentar novos serviços sem incorrer em custos adicionais. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Centro de Arquitetura da AWS](https://aws.amazon.com/architecture/) 
+  [AWS Partner Network](https://aws.amazon.com/partners/) 
+  [Biblioteca de Soluções da AWS](https://aws.amazon.com/solutions/) 
+  [Central de Conhecimento da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [Crie aplicações modernas na AWS](https://aws.amazon.com/modern-apps/) 

 **Vídeos relacionados:** 
+  [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/) 

 **Exemplos relacionados:** 
+  [Amostras da AWS](https://github.com/aws-samples) 
+  [Exemplos de SDKs da AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 

# PERF01-BP02 Use a orientação de seu provedor de nuvem ou de um parceiro apropriado para aprender sobre padrões de arquitetura e práticas recomendadas
<a name="perf_architecture_guidance_architecture_patterns_best_practices"></a>

 Use recursos disponibilizados pelo fornecedor de nuvem, como documentação, arquitetos de soluções, serviços profissionais ou parceiros apropriados, para orientar suas decisões durante a escolha da arquitetura. Eles ajudarão a analisar e melhorar sua arquitetura para alcançar a performance ideal. 

 **Antipadrões comuns:** 
+  Você usa a AWS como um provedor de nuvem comum. 
+  Você usa as ofertas da AWS de uma maneira para a qual elas não foram projetadas. 
+  Você segue todas as orientações sem considerar seu contexto de negócios. 

 **Benefícios de estabelecer esta prática recomendada:** Usar a orientação de um provedor de nuvem ou de um parceiro apropriado pode ajudar a fazer as escolhas de arquitetura certas para as workloads e ter confiança em suas decisões. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A AWS oferece uma ampla variedade de orientações, documentações e recursos que podem ajudar a criar e gerenciar workloads eficientes na nuvem. A documentação da AWS fornece exemplos de código, tutoriais e explicações detalhadas do serviço. Além da documentação, a AWS fornece programas de treinamento e certificação, arquitetos de soluções e serviços profissionais que podem ajudar os clientes a explorar diferentes aspectos dos serviços em nuvem e implementar uma arquitetura de nuvem eficiente na AWS. 

 Aproveite esses recursos para obter informações sobre conhecimentos valiosos e práticas recomendadas, economizar tempo e obter melhores resultados na Nuvem AWS. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Analise a documentação e as orientações da AWS e siga as práticas recomendadas. Esses recursos podem ajudar a escolher e configurar serviços com eficiência e obter melhor performance. 
  +  [Documentação da AWS](https://docs.aws.amazon.com/) (como guias do usuário e whitepapers) 
  +  [Blog da AWS](https://aws.amazon.com/blogs/) 
  +  [Treinamento da AWS and Certifications](https://www.aws.training/) 
  +  [Canal da AWS no Youtube](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg) 
+  Participe de eventos de parceiros da AWS (como Conferências Globais da AWS, AWS re:Invent, grupos de usuários e workshops) para ouvir dos próprios especialistas da AWS quais são as práticas recomendadas no uso dos serviços da empresa. 
  +  [Eventos e webinars da AWS](https://aws.amazon.com/events/) 
  +  [Workshops da AWS](https://workshops.aws/) 
  +  [Comunidades da AWS](https://aws.amazon.com/events/asean/community-and-events/) 
+  Entre em contato com a AWS para obter assistência quando precisar de mais orientações ou informações sobre produtos. Os arquitetos de soluções da AWS e o [AWS Professional Services](https://aws.amazon.com/professional-services/) fornecem orientação para a implementação da solução. [parceiros da AWS](https://aws.amazon.com/partners/) oferecem toda a experiência na AWS para ajudar você a adquirir agilidade e inovação para os negócios. 
+  Use [Suporte](https://aws.amazon.com/contact-us/) se precisar de suporte técnico para otimizar o uso de um serviço. [Nossos planos de suporte](https://aws.amazon.com/premiumsupport/plans/) são projetados a fim de oferecer a combinação certa de ferramentas e acesso ao conhecimento especializado para ter sucesso com a AWS e melhorar a performance, gerenciar riscos e manter os custos sob controle. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Centro de Arquitetura da AWS](https://aws.amazon.com/architecture/) 
+  [Biblioteca de Soluções da AWS](https://aws.amazon.com/solutions/) 
+  [Central de Conhecimento da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [AWS Enterprise Support](https://aws.amazon.com/premiumsupport/plans/enterprise/) 

 **Vídeos relacionados:** 
+  [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/) 

 **Exemplos relacionados:** 
+  [Amostras da AWS](https://github.com/aws-samples) 
+  [Exemplos de SDKs da AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 

# PERF01-BP03 Inclua o custo nas decisões de arquitetura
<a name="perf_architecture_factor_cost_into_architectural_decisions"></a>

 Considere o custo em suas decisões de arquitetura para melhorar a utilização de recursos e a eficiência da performance de suas workloads na nuvem. Quando você está ciente das implicações de custo de suas workloads na nuvem, é mais provável que utilize recursos eficientes e reduza práticas ineficazes. 

 **Antipadrões comuns:** 
+  Você só usa uma família de instâncias. 
+  Você não avalia soluções licenciadas em relação a soluções de código aberto. 
+  Você não define políticas de ciclo de vida de armazenamento. 
+  Você não analisa os novos serviços e recursos da Nuvem AWS. 
+  Você só usa o armazenamento em bloco. 

 **Benefícios de estabelecer esta prática recomendada:** Levar em conta o custo em sua tomada de decisão permite que você use recursos mais eficientes e examine outros investimentos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Otimizar as workloads em função do custo pode melhorar a utilização dos recursos e evitar o desperdício em uma workload na nuvem. A consideração do custo nas decisões de arquitetura geralmente inclui o dimensionamento correto dos componentes da workload e a viabilização da elasticidade, o que resulta em maior eficiência da sua performance na nuvem. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Estabeleça objetivos de custo, como limites orçamentários para a workload na nuvem. 
+  Identifique os principais componentes (como instâncias e armazenamento) que impulsionam o custo da workload. Você pode usar o [AWS Calculadora de Preços](https://calculator.aws/#/) e o [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) para identificar os principais fatores de custo na workload. 
+  Use [práticas recomendadas de otimização de custos do Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) para otimizar esses componentes principais em termos de custo. 
+  Monitore e analise constantemente os custos para identificar oportunidades de otimizar as workloads e economizar. 
  +  Use [o AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) para receber alertas quando os custos forem inaceitáveis. 
  +  Use [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) ou [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) para receber recomendações de otimização de custos. 
  +  Use [Detecção de Anomalias de Custos da AWS](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) para obter detecção automática de anomalias de custo e análise da causa raiz. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [A Detailed Overview of the Cost Intelligence Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/a-detailed-overview-of-the-cost-intelligence-dashboard/) 
+  [Centro de Arquitetura da AWS](https://aws.amazon.com/architecture/) 
+  [AWS Partner Network](https://aws.amazon.com/partners/) 
+  [Biblioteca de Soluções da AWS](https://aws.amazon.com/solutions/) 
+  [Central de Conhecimento da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 

 **Vídeos relacionados:** 
+  [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/) 
+  [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg&ref=wellarchitected) 

 **Exemplos relacionados:** 
+  [Amostras da AWS](https://github.com/aws-samples) 
+  [Exemplos de SDKs da AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 
+  [Rightsizing with Compute Optimizer and Memory utilization enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 
+  [AWS Compute Optimizer Demo code](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) 

# PERF01-BP04 Avalie como certas trocas (trade-offs) afetam os clientes e a eficiência da arquitetura
<a name="perf_architecture_evaluate_trade_offs"></a>

 Ao avaliar melhorias relacionadas ao desempenho, determine quais escolhas afetam os clientes e a eficiência das workloads. Por exemplo, se o uso de um datastore de chave-valor aumentar o desempenho do sistema, é importante avaliar como a mudança afetará os clientes após tornar-se consistente. 

 **Antipadrões comuns:** 
+  Você pressupõe que todos os ganhos de desempenho devem ser implementados, mesmo que seja preciso fazer certas trocas para implementação. 
+  Você só avalia alterações nas workloads quando um problema de performance atinge um ponto crítico. 

 **Benefícios de estabelecer esta prática recomendada:** Ao avaliar possíveis melhorias relacionadas à performance, você deve decidir se as concessões para as alterações são aceitáveis com os requisitos da workload. Em alguns casos, pode ser necessário implementar controles adicionais para compensar as compensações. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Identifique áreas críticas na arquitetura em termos de desempenho e impacto para o cliente. Determine como você pode promover aprimoramentos, quais concessões esses aprimoramentos exigem e como elas afetam o sistema e a experiência do usuário. Por exemplo, a implementação de armazenamento de dados em cache pode ajudar a aprimorar drasticamente a performance, mas requer uma estratégia clara de como e quando atualizar ou invalidar dados em cache a fim de prevenir comportamentos incorretos do sistema. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Entenda SLAs e requisitos de suas workloads. 
+  Defina claramente os fatores de avaliação. Os fatores podem estar relacionados a custo, confiabilidade, segurança e desempenho de suas workloads. 
+  Selecione arquitetura e serviços que possam atender às suas necessidades. 
+  Realize experiências e provas de conceitos (POCs) para avaliar os fatores e o impacto de certas trocas para os clientes e para a eficiência da arquitetura. Normalmente, workloads de alta disponibilidade, com bom desempenho e seguras consomem mais recursos da nuvem e, ao mesmo tempo, proporcionam uma melhor experiência ao cliente. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon Builders’ Library](https://aws.amazon.com/builders-library) 
+  [Quick KPIs](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html) 
+  [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 
+  [Documentação do X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+ [ Understand resiliency patterns and trade-offs to architect efficiently in the cloud ](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)

 **Vídeos relacionados:** 
+  [Build a monitoring plan](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) 
+  [Optimize applications through Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y) 
+  [Demo of Amazon CloudWatch Synthetics (Demonstração do Amazon CloudWatch Synthetics)](https://www.youtube.com/watch?v=hF3NM9j-u7I) 

 **Exemplos relacionados:** 
+  [Measure page load time with Amazon CloudWatch Synthetics (Medição do tempo de carga da página com o Amazon CloudWatch Synthetics)](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance) 
+  [Amazon CloudWatch RUM Web Client (Cliente da web do Amazon CloudWatch RUM)](https://github.com/aws-observability/aws-rum-web) 

# PERF01-BP05 Use políticas e arquiteturas de referência
<a name="perf_architecture_use_policies_and_reference_architectures"></a>

 Use políticas internas e arquiteturas de referência existentes ao selecionar serviços e configurações para ser mais eficiente ao projetar e implementar a workload. 

 **Antipadrões comuns:** 
+  Você permite uma ampla variedade de tecnologias que podem afetar os custos de gerenciamento da empresa. 

 **Benefícios de estabelecer esta prática recomendada:** Estabelecer uma política para opções de arquitetura, tecnologia e fornecedor permite que as decisões sejam tomadas rapidamente. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Ter políticas internas na seleção de recursos e arquitetura fornece padrões e diretrizes a serem seguidos ao fazer escolhas arquitetônicas. Essas diretrizes simplificam o processo de tomada de decisão ao escolher o serviço de nuvem certo e podem ajudar a melhorar a eficiência da performance. Implante a workload usando políticas ou arquiteturas de referência. Integre os serviços à implantação na nuvem e, depois, use testes de desempenho para verificar se você pode continuar a atender aos seus requisitos de desempenho. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Entenda claramente os requisitos de sua workload na nuvem. 
+  Analise as políticas internas e externas para identificar as mais relevantes. 
+  Use as arquiteturas de referência apropriadas fornecidas pela AWS ou as práticas recomendadas do seu setor. 
+  Crie um continuum que consiste em políticas, padrões, arquiteturas de referência e diretrizes prescritivas para situações comuns. Isso permite que suas equipes ajam mais rapidamente. Adapte os ativos para sua vertical, se aplicável. 
+  Valide essas políticas e arquiteturas de referência para sua workload em ambientes de sandbox. 
+  Atualize-se com relação aos padrões do setor e atualizações da AWS para garantir que suas políticas e arquiteturas de referência ajudem a otimizar sua workload na nuvem. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Centro de Arquitetura da AWS](https://aws.amazon.com/architecture/) 
+  [AWS Partner Network](https://aws.amazon.com/partners/) 
+  [Biblioteca de Soluções da AWS](https://aws.amazon.com/solutions/) 
+  [Central de Conhecimento da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 

 **Vídeos relacionados:** 
+  [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/) 

 **Exemplos relacionados:** 
+  [Amostras da AWS](https://github.com/aws-samples) 
+  [Exemplos de SDKs da AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 

# PERF01-BP06 Use testes comparativos para orientar decisões de arquitetura
<a name="perf_architecture_use_benchmarking"></a>

 Compare o desempenho de uma workload existente para entender seu desempenho na nuvem e orientar decisões de arquitetura com base nesses dados. 

 **Antipadrões comuns:** 
+  Você depende de testes comparativos comuns que não são indicativos das características da workload. 
+  Você conta com o feedback e as percepções de clientes como seu único teste comparativo. 

 **Benefícios de estabelecer esta prática recomendada:** Os testes comparativos da implementação atual permitem medir a melhoria da performance. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Use testes comparativos com testes sintéticos para avaliar a performance dos componentes da workload. O benchmarking é usado na avaliação da tecnologia para um componente específico e geralmente é mais simples de configurar do que testes de carga. Muitas vezes o benchmarking é usado no início de um novo projeto, quando ainda não há uma solução completa para o teste de carga. 

 É possível criar os próprios testes comparativos personalizados ou usar um teste padrão do setor, como o [TPC-DS](http://www.tpc.org/tpcds/), para comparar as workloads. Os benchmarks do setor são úteis ao comparar ambientes. Já os benchmarks personalizados são úteis para direcionar a tipos específicos de operações que você espera realizar em sua arquitetura. 

 Ao realizar testes comparativos, é importante “preaquecer” o ambiente de teste para obter resultados válidos. Execute o mesmo teste comparativo várias vezes para verificar a captura de qualquer variação ao longo do tempo. 

 Como normalmente é mais rápido executar testes comparativos do que testes de carga, eles podem ser usados mais cedo no pipeline de implantação e fornecer um feedback mais rápido sobre desvios de performance. Ao avaliar uma alteração significativa em um componente ou serviço, um benchmark pode ser uma maneira rápida de verificar se é possível justificar a iniciativa para concretizar a alteração. O uso de testes comparativos em conjunto com testes de carga é importante porque o teste de carga informa como é a performance da workload em produção. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Defina as métricas (como utilização da CPU, latência ou throughput) para avaliar o desempenho da workload. 
+  Identifique e configure uma ferramenta de testes comparativos adequada à workload. Você pode usar serviços da AWS (como o [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)) ou uma ferramenta de terceiros compatível com a workload. 
+  Execute testes comparativos e monitore as métricas durante o teste. 
+  Analise e documente os resultados do teste comparativo para identificar gargalos e problemas. 
+  Use os resultados do teste para tomar decisões de arquitetura e ajustar a workload. Isso pode incluir a mudança de serviços ou a adoção de novos recursos. 
+  Teste novamente a workload após o ajuste. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Centro de Arquitetura da AWS](https://aws.amazon.com/architecture/) 
+  [AWS Partner Network](https://aws.amazon.com/partners/) 
+  [Biblioteca de Soluções da AWS](https://aws.amazon.com/solutions/) 
+  [Central de Conhecimento da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 
+  [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 

 **Vídeos relacionados:** 
+  [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/) 
+  [Optimize applications through Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y) 
+  [Demo of Amazon CloudWatch Synthetics (Demonstração do Amazon CloudWatch Synthetics)](https://www.youtube.com/watch?v=hF3NM9j-u7I) 

 **Exemplos relacionados:** 
+  [Amostras da AWS](https://github.com/aws-samples) 
+  [Exemplos de SDKs da AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 
+  [Distributed Load Tests](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 
+  [Measure page load time with Amazon CloudWatch Synthetics (Medição do tempo de carga da página com o Amazon CloudWatch Synthetics)](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance) 
+  [Amazon CloudWatch RUM Web Client (Cliente da web do Amazon CloudWatch RUM)](https://github.com/aws-observability/aws-rum-web) 

# PERF01-BP07 Use uma abordagem baseada em dados para escolhas de arquitetura
<a name="perf_architecture_use_data_driven_approach"></a>

 Defina uma abordagem clara e baseada em dados para escolhas de arquitetura a fim de verificar se os serviços e configurações de nuvem corretos são usados para atender às suas necessidades comerciais específicas. 

 **Antipadrões comuns:** 
+  Você pressupõe que sua arquitetura atual é estática e não deve ser atualizada ao longo do tempo. 
+  Suas escolhas de arquitetura são baseadas em suposições. 
+  Você apresenta alterações de arquitetura ao longo do tempo sem justificativa. 

 **Benefícios de estabelecer esta prática recomendada:** Ao ter uma abordagem bem definida para fazer escolhas de arquitetura, você usa dados para influenciar o projeto das workloads e tomar decisões conscientes ao longo do tempo. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Use a experiência interna e o conhecimento da nuvem ou de recursos externos, como casos de uso publicados ou whitepapers, para escolher recursos e serviços em sua arquitetura. Você deve ter um processo bem definido que incentive a experimentação e os testes comparativos com os serviços que podem ser usados em suas workloads. 

 Os atrasos de workloads críticas devem consistir não apenas em histórias de usuários que venham a oferecer funcionalidades relevantes para empresas e usuários, mas também em histórias técnicas que formem uma base de arquitetura para as workloads. Essa base é formada por novos avanços em tecnologia e novos serviços e os adota com base em dados e justificativas adequadas. Isso verifica se a arquitetura permanece preparada para o futuro e não fica estagnada. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Interaja com as principais partes interessadas para definir os requisitos das workloads, incluindo considerações de desempenho, disponibilidade e custo. Considere fatores como o número de usuários e o padrão de uso das workloads. 
+  Crie uma base de arquitetura ou uma lista de pendências de tecnologia que seja priorizada junto com a lista de pendências funcional. 
+  Avalie diferentes serviços em nuvem (para obter mais detalhes, consulte [PERF01-BP01 Conheça e compreenda os serviços e recursos de nuvem disponíveis](perf_architecture_understand_cloud_services_and_features.md)). 
+  Explore diferentes padrões de arquitetura, como microsserviços ou tecnologia sem servidor, que atendem aos requisitos de performance (para obter mais detalhes, consulte [PERF01-BP02 Use a orientação de seu provedor de nuvem ou de um parceiro apropriado para aprender sobre padrões de arquitetura e práticas recomendadas](perf_architecture_guidance_architecture_patterns_best_practices.md)). 
+  Consulte outras equipes, diagramas de arquitetura e recursos, como arquitetos de soluções da AWS, [Centro de Arquitetura da AWS](https://aws.amazon.com/architecture/)e [AWS Partner Network](https://aws.amazon.com/partners/), para ajudar você a escolher a arquitetura certa para sua workload. 
+  Defina métricas de desempenho, como produtividade e tempo de resposta, que podem ajudar você a avaliar o desempenho das workloads. 
+  Experimente e use métricas definidas para validar o desempenho da arquitetura selecionada. 
+  Monitore e faça ajustes contínuos conforme necessário para manter o desempenho ideal da arquitetura. 
+  Documente a arquitetura e as decisões selecionadas como referência para futuras atualizações e aprendizados. 
+  Revise e atualize constantemente a abordagem para seleção de arquitetura com base em aprendizados, novas tecnologias e métricas. Esses parâmetros podem indicar que é necessário mudar ou que há algum problema na abordagem atual. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Biblioteca de Soluções da AWS](https://aws.amazon.com/solutions/) 
+  [Central de Conhecimento da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 

 **Vídeos relacionados:** 
+  [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/) 

 **Exemplos relacionados:** 
+  [Amostras da AWS](https://github.com/aws-samples) 
+  [Exemplos de SDKs da AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 

# Computação e hardware
<a name="a-compute-hardware"></a>

# PERFORMANCE 2. Como você seleciona e usa recursos computacionais em sua workload?
<a name="perf-02"></a>

 A opção ideal de computação para uma workload específica pode variar de acordo com o design, os padrões de uso e as definições de configuração da aplicação. As arquiteturas podem usar diferentes opções de computação para vários componentes e permitir diferentes recursos para aprimorar a performance. A seleção da opção de computação incorreta para uma arquitetura pode levar a uma menor eficiência de performance. 

**Topics**
+ [PERF02-BP01 Selecione as melhores opções de computação para as workloads](perf_compute_hardware_select_best_compute_options.md)
+ [PERF02-BP02 Entenda a configuração e os recursos de computação disponíveis](perf_compute_hardware_understand_compute_configuration_features.md)
+ [PERF02-BP03 Colete métricas relacionadas à computação](perf_compute_hardware_collect_compute_related_metrics.md)
+ [PERF02-BP04 Configure e dimensione corretamente os recursos de computação](perf_compute_hardware_configure_and_right_size_compute_resources.md)
+ [PERF02-BP05 Dimensione recursos de computação dinamicamente](perf_compute_hardware_scale_compute_resources_dynamically.md)
+ [PERF02-BP06 Use optimized hardware-based compute accelerators](perf_compute_hardware_compute_accelerators.md)

# PERF02-BP01 Selecione as melhores opções de computação para as workloads
<a name="perf_compute_hardware_select_best_compute_options"></a>

 Selecionar a opção de computação mais adequada para suas workloads permite que você melhore o desempenho, reduza os custos desnecessários de infraestrutura e reduza os esforços operacionais necessários para mantê-las. 

 **Antipadrões comuns:** 
+  É usada a mesma opção de computação utilizada on-premises. 
+  Você não tem conhecimento das opções, dos atributos e das soluções de computação em nuvem e de como essas soluções podem melhorar a performance computacional. 
+  É provisionada em excesso uma opção de computação existente para atender aos requisitos de ajuste de escala ou performance quando uma opção alternativa de computação se alinharia às características da workload com mais precisão. 

 **Benefícios de estabelecer esta prática recomendada:** Ao identificar os requisitos de computação e avaliar as opções disponíveis, você pode tornar a workload mais eficiente em termos de recursos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Para otimizar as workloads na nuvem quanto à eficiência de desempenho, é importante selecionar as opções de computação mais apropriadas para seu caso de uso e requisitos de desempenho. A AWS fornece uma variedade de opções de computação que atendem a diferentes workloads na nuvem. Por exemplo, você pode usar o [Amazon EC2](https://docs.aws.amazon.com/ec2/) para iniciar e gerenciar servidores virtuais, o [AWS Lambda](https://docs.aws.amazon.com/lambda/?icmpid=docs_homepage_featuredsvcs) para executar código sem precisar provisionar nem gerenciar servidores, o [Amazon ECS](https://aws.amazon.com/ecs/) ou [Amazon EKS](https://aws.amazon.com/eks/) para executar e gerenciar contêineres ou [AWS Batch](https://aws.amazon.com/batch/) para processar grandes volumes de dados em paralelo. Com base em sua escala e necessidades de computação, você deve escolher e configurar a solução ideal para sua situação. Você também pode considerar o uso de vários tipos de soluções de computação em uma única workload, pois cada uma tem suas próprias vantagens e desvantagens. 

 As etapas a seguir orientam você na seleção das opções de computação certas para atender às características da workload e aos requisitos de desempenho. 

## Etapas da implementação
<a name="implementation-steps"></a>

1.  Entenda os requisitos de computação das workloads. Os principais requisitos a serem considerados incluem necessidades de processamento, padrões de tráfego, padrões de acesso a dados, necessidades de ajuste de escala e requisitos de latência. 

1.  Saiba mais sobre as diferentes opções de computação disponíveis para a workload na AWS (conforme descrito em [PERF01-BP01 Conheça e compreenda os serviços e recursos de nuvem disponíveis](perf_architecture_understand_cloud_services_and_features.md). Veja algumas das principais opções de computação da AWS, as características e casos de uso comuns:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_compute_hardware_select_best_compute_options.html)

1.  Avalie o custo (como cobrança por hora ou transferência de dados) e as despesas gerais de gerenciamento (como aplicação de patches e ajuste de escala) associados a cada opção de computação. 

1.  Faça experimentos e análises comparativas em um ambiente que não seja de produção para identificar qual opção de computação pode melhor atender às necessidades da workload. 

1.  Depois de experimentar e identificar sua nova solução de computação, planeje a migração e valide as métricas de desempenho. 

1.  Use ferramentas de monitoramento da AWS, como [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) e serviços de otimização, como [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) para otimizar continuamente os recursos de computação com base em padrões de uso do mundo real. 

 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Cloud Compute with AWS ](https://aws.amazon.com/products/compute/?ref=wellarchitected) 
+  [Amazon EC2 Instance Types ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html?ref=wellarchitected) 
+  [Amazon EKS Containers: Amazon EKS Worker Nodes ](https://docs.aws.amazon.com/eks/latest/userguide/worker.html?ref=wellarchitected) 
+  [Amazon ECS Containers: Amazon ECS Container Instances ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html?ref=wellarchitected) 
+  [Funções: configuração de função do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html?ref=wellarchitected#function-configuration) 
+ [Prescriptive Guidance for Containers](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortText&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23containers&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all) 
+  [Prescriptive Guidance for Serverless](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortText&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23serverless&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all) 

 **Vídeos relacionados:** 
+  [How to choose compute option for startups (Como escolher uma opção de computação para startups)](https://aws.amazon.com/startups/start-building/how-to-choose-compute-option/) 
+  [Optimize performance and cost for your AWS compute ](https://www.youtube.com/watch?v=zt6jYJLK8sg) 
+  [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system ](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected) 
+  [Deploy ML models for inference at high performance and low cost](https://www.youtube.com/watch?v=4FqHt5bmS2o) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2](https://www.youtube.com/watch?v=_dvh4P2FVbw&ref=wellarchitected) 

 **Exemplos relacionados:** 
+  [Migrating the Web application to containers](https://application-migration-with-aws.workshop.aws/en/container-migration.html) 
+  [Run a Serverless Hello World](https://aws.amazon.com/getting-started/hands-on/run-serverless-code/) 

# PERF02-BP02 Entenda a configuração e os recursos de computação disponíveis
<a name="perf_compute_hardware_understand_compute_configuration_features"></a>

 Entenda as opções de configuração e os recursos disponíveis para seu serviço de computação a fim de ajudar a provisionar a quantidade certa de recursos e melhorar a eficiência do desempenho. 

 **Antipadrões comuns:** 
+  Você não avalia as opções de computação ou as famílias de instâncias disponíveis em relação às características da workload. 
+  Você provisiona recursos de computação em excesso para atender aos requisitos de pico de demanda. 

** Benefícios de estabelecer esta prática recomendada:** familiarizar-se com os atributos e as configurações de computação da AWS a fim de poder usar uma solução de computação otimizada para atender às características e às necessidades da workload.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Cada solução de computação tem configurações e recursos exclusivos disponíveis para suportar diferentes características e requisitos das workloads. Saiba como essas opções complementam sua workload e determine quais opções de configuração são melhores para sua aplicação. Exemplos dessas opções são famílias de instâncias, tamanhos, recursos (GPU, E/S), expansão, tempos limite, tamanhos de função, instâncias de contêineres e simultaneidade. Se a workload estiver usando a mesma opção de computação há mais de quatro semanas, e se a previsão for de que as características permanecerão as mesmas no futuro, você poderá usar o [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)  para descobrir se a opção de computação atual é adequada para as workloads do ponto de vista da CPU e da memória. 

## Etapas da implementação
<a name="implementation-steps"></a>

1.  Entenda os requisitos da workload (como necessidade de CPU, memória e latência). 

1.  Analise a documentação e as práticas recomendadas da AWS para saber mais sobre as opções de configuração indicadas que podem ajudar a melhorar a performance da computação. Aqui estão algumas das principais opções de configuração a serem consideradas:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_compute_hardware_understand_compute_configuration_features.html)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Cloud Compute with AWS ](https://aws.amazon.com/products/compute/?ref=wellarchitected) 
+  [Amazon EC2 Instance Types ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html?ref=wellarchitected) 
+  [Processor State Control for Your Amazon EC2 Instance ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html?ref=wellarchitected) 
+  [Amazon EKS Containers: Amazon EKS Worker Nodes ](https://docs.aws.amazon.com/eks/latest/userguide/worker.html?ref=wellarchitected) 
+  [Amazon ECS Containers: Amazon ECS Container Instances ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html?ref=wellarchitected) 
+  [Funções: configuração de função do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html?ref=wellarchitected#function-configuration) 

 **Vídeos relacionados:** 
+  [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system ](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected) 
+  [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg&ref=wellarchitected) 

 **Exemplos relacionados:** 
+  [Rightsizing with Compute Optimizer and Memory utilization enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 
+  [AWS Compute Optimizer Demo code](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) 

# PERF02-BP03 Colete métricas relacionadas à computação
<a name="perf_compute_hardware_collect_compute_related_metrics"></a>

 Registre e acompanhe métricas relacionadas à computação para entender melhor o desempenho de seus recursos e melhorar seu desempenho e utilização. 

 **Antipadrões comuns:** 
+  Você só usa a pesquisa manual de arquivos de log para métricas.  
+  Você só usa as métricas padrão registradas pelo software de monitoramento. 
+  Você só revisa as métricas quando há um problema. 

 **Benefícios de estabelecer esta prática recomendada:** A coleta de métricas relacionadas à performance ajudará você a alinhar a performance da aplicação aos requisitos empresariais para garantir que você atenda às necessidades da workload. Isso também pode ajudar a melhorar constantemente o desempenho e a utilização dos recursos na workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 As workloads na nuvem podem gerar grandes volumes de dados, como métricas, logs e eventos. Na Nuvem AWS, coletar métricas é uma etapa essencial para melhorar a segurança, a eficiência de custos, a performance e a sustentabilidade. A AWS oferece uma ampla variedade de métricas relacionadas à performance usando serviços de monitoramento, por exemplo, o [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) para fornecer informações valiosas. Métricas como utilização de CPU, utilização de memória, E/S de disco e entrada e saída da rede podem fornecer informações sobre os níveis de utilização ou gargalos de desempenho. Use essas métricas como parte de uma abordagem impulsionada por dados para ajustar e otimizar ativamente os recursos de sua carga de trabalho.  Em um caso ideal, você deve coletar todas as métricas relacionadas aos recursos de computação em uma única plataforma com políticas de retenção implementadas para apoiar as metas operacionais e de custo. 

## Etapas da implementação
<a name="implementation-steps"></a>

1.  Identifique quais métricas relacionadas ao desempenho são relevantes para a workload. Você deve coletar métricas sobre a utilização de recursos e a forma como a workload na nuvem está operando (como tempo de resposta e throughput). 

   1.  [Métricas padrão do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) 

   1.  [Métricas padrão do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch-metrics.html) 

   1.  [Métricas padrão do Amazon EKS](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/kubernetes-eks-metrics.html) 

   1.  [Métricas padrão do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html) 

   1.  [Métricas de memória e disco do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html) 

1.  Escolha e configure a solução certa de registro e monitoramento para a workload. 

   1.  [Observabilidade nativa da AWS](https://catalog.workshops.aws/observability/en-US/aws-native) 

   1.  [AWS Distro para OpenTelemetry](https://aws.amazon.com/otel/) 

   1.  [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/grafana/latest/userguide/prometheus-data-source.html) 

1.  Defina o filtro e a agregação necessários para as métricas com base nos requisitos da workload. 

   1.  [Quantify custom application metrics with Amazon CloudWatch Logs and metric filters](https://aws.amazon.com/blogs/mt/quantify-custom-application-metrics-with-amazon-cloudwatch-logs-and-metric-filters/) 

   1.  [Collect custom metrics with Amazon CloudWatch strategic tagging](https://aws.amazon.com/blogs/infrastructure-and-automation/collect-custom-metrics-with-amazon-cloudwatch-strategic-tagging/) 

1.  Configure políticas de retenção de dados para que as métricas correspondam às metas operacionais e de segurança. 

   1.  [Retenção de dados padrão para métricas do CloudWatch](https://aws.amazon.com/cloudwatch/faqs/#AWS_resource_.26_custom_metrics_monitoring) 

   1.  [Retenção de dados padrão para o CloudWatch Logs](https://aws.amazon.com/cloudwatch/faqs/#Log_management) 

1.  Se necessário, crie alarmes e notificações para as métricas a fim de ajudar a reagir proativamente a problemas relacionados à performance. 

   1.  [Create alarms for custom metrics using Amazon CloudWatch anomaly detection](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection.html) 

   1.  [Create metrics and alarms for specific web pages with Amazon CloudWatch RUM](https://aws.amazon.com/blogs/mt/create-metrics-and-alarms-for-specific-web-pages-amazon-cloudwatch-rum/) 

1.  Use a automação para implantar os agentes de agregação de métricas e logs. 

   1.  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html?ref=wellarchitected) 

   1.  [OpenTelemetry Collector](https://aws-otel.github.io/docs/getting-started/collector) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Documentação do Amazon CloudWatch](https://docs.aws.amazon.com/cloudwatch/index.html?ref=wellarchitected) 
+  [Collect metrics and logs from Amazon EC2 instances and on-premises servers with the CloudWatch Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected) 
+  [Acessar o Amazon CloudWatch Logs para o AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html?ref=wellarchitected) 
+  [Using CloudWatch Logs with container instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html?ref=wellarchitected) 
+  [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html?ref=wellarchitected) 
+  [AWS Answers: Centralized Logging](https://aws.amazon.com/answers/logging/centralized-logging/?ref=wellarchitected) 
+  [AWS Services That Publish CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html?ref=wellarchitected) 
+  [Monitoring Amazon EKS on AWS Fargate](https://aws.amazon.com/blogs/containers/monitoring-amazon-eks-on-aws-fargate-using-prometheus-and-grafana/) 

 **Vídeos relacionados:** 
+  [Application Performance Management on AWS](https://www.youtube.com/watch?v=5T4stR-HFas&ref=wellarchitected) 

 **Exemplos relacionados:** 
+  [Level 100: Monitoring with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) 
+  [Level 100: Monitoring Windows EC2 instance with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_windows_ec2_cloudwatch/) 
+  [Level 100: Monitoring an Amazon Linux EC2 instance with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_linux_ec2_cloudwatch/) 

# PERF02-BP04 Configure e dimensione corretamente os recursos de computação
<a name="perf_compute_hardware_configure_and_right_size_compute_resources"></a>

 Configure e dimensione corretamente os recursos de computação para atender aos requisitos de desempenho das workloads e evitar que recursos sejam subutilizados ou usados em excesso. 

 **Antipadrões comuns:** 
+  Ignorar os requisitos de performance das workloads, o que ocasiona recursos computacionais superprovisionados ou subprovisionados. 
+  Você escolhe somente a maior ou a menor instância disponível para todas as workloads. 
+  Você usa apenas uma família de instâncias para facilitar o gerenciamento. 
+  Você ignora as recomendações de AWS Cost Explorer ou Compute Optimizer para o dimensionamento correto. 
+  Você não reavalia a workload quanto à adequação dos novos tipos de instância. 
+  Você certifica apenas um pequeno número de configurações de instâncias para sua organização. 

 **Benefícios de estabelecer esta prática recomendada:** o dimensionamento correto dos recursos computacionais garante a operação ideal na nuvem, evitando o provisionamento excessivo e o subprovisionamento de recursos. O dimensionamento adequado dos recursos de computação normalmente resulta em melhor desempenho e melhor experiência do cliente, além de reduzir custos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 O dimensionamento correto permite que as organizações operem a infraestrutura de nuvem de forma eficiente e econômica, ao mesmo tempo em que atendem às suas necessidades comerciais. O provisionamento excessivo de recursos de nuvem pode gerar custos extras, enquanto o subprovisionamento pode ocasionar performance ruim e uma experiência negativa para o cliente. A AWS oferece ferramentas, como o [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) e o [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) , que usam dados históricos com o objetivo de fornecer recomendações para dimensionar corretamente os recursos computacionais. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Escolha um tipo de instância que melhor atenda às suas necessidades: 
  +  [Como faço para escolher o tipo de instância do Amazon EC2 apropriado para minha workload?](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/) 
  +  [Seleção de tipo de instância baseada em atributos para frota do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) 
  +  [Create an Auto Scaling group using attribute-based instance type selection](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) 
  +  [Optimizing your Kubernetes compute costs with Karpenter consolidation (Otimizar seus custos de computação do Kubernetes com a consolidação do Karpenter)](https://aws.amazon.com/blogs/containers/optimizing-your-kubernetes-compute-costs-with-karpenter-consolidation/) 
+  Analise as várias características de performance de sua carga de trabalho e como elas se relacionam a uso de memória, rede e CPU. Use esses dados para escolher os recursos que melhor correspondam ao perfil e às metas de desempenho da workload. 
+  Monitore o uso de recursos usando ferramentas de monitoramento da AWS, como o Amazon CloudWatch. 
+  Selecione a configuração correta para os recursos computacionais. 
  +  Para workloads efêmeras, avalie [métricas do Amazon CloudWatch para instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) , como `CPUUtilization` para identificar se a instância está subutilizada ou superutilizada. 
  +  Para workloads estáveis, verifique as ferramentas de dimensionamento correto da AWS, como AWS Compute Optimizer e AWS Trusted Advisor em intervalos regulares, para identificar oportunidades de otimizar e dimensionar corretamente o recurso de computação. 
    +  [Laboratório do Well-Architected: Recomendações de dimensionamento correto ](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/) 
    +  [Laboratório do Well-Architected: Dimensionamento correto com o Compute Optimizer ](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/) 
+  Teste as alterações na configuração em um ambiente que não seja de produção antes de implementá-las em um ambiente ativo. 
+  Reavalie constantemente novas ofertas de computação e as compare com as necessidades da workload. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Cloud Compute with AWS](https://aws.amazon.com/products/compute/) 
+  [Amazon EC2 Instance Types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) 
+  [Amazon ECS Containers: Amazon ECS Container Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html) 
+  [Amazon EKS Containers: Amazon EKS Worker Nodes](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) 
+  [Funções: configuração de função do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) 
+  [Processor State Control for Your Amazon EC2 Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html) 

 **Vídeos relacionados:** 
+  [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2](https://www.youtube.com/watch?v=_dvh4P2FVbw) 
+  [Deploy ML models for inference at high performance and low cost](https://www.youtube.com/watch?v=4FqHt5bmS2o) 
+  [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4) 
+  [Como simplificar o processamento de dados para aprimorar a inovação com ferramentas de tecnologia sem servidor](https://aws.amazon.com/startups/start-building/how-to-choose-compute-option/) 

 **Exemplos relacionados:** 
+  [Rightsizing with Compute Optimizer and Memory utilization enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 
+  [AWS Compute Optimizer Demo code](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) 

# PERF02-BP05 Dimensione recursos de computação dinamicamente
<a name="perf_compute_hardware_scale_compute_resources_dynamically"></a>

 Use a elasticidade da nuvem para aumentar ou diminuir os recursos de computação dinamicamente a fim de atender às suas necessidades e evitar provisionamento excessivo ou insuficiente da capacidade para a workload. 

 **Antipadrões comuns:** 
+  Você reage a alarmes aumentando a capacidade manualmente. 
+  Você usa as mesmas diretrizes de dimensionamento (geralmente infraestrutura estática) do ambiente on-premises. 
+  Você deixa a capacidade aumentada após um evento de escalabilidade, em vez de reduzir novamente. 

 **Benefícios de estabelecer esta prática recomendada:** Configurar e testar a elasticidade dos recursos computacionais pode ajudar você a economizar dinheiro, manter os benchmarks de performance e melhorar a confiabilidade à medida que o tráfego muda. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A AWS oferece a flexibilidade de aumentar ou diminuir seus recursos dinamicamente por meio de uma variedade de mecanismos de ajuste de escala a fim de atender às mudanças na demanda. Combinado com métricas relacionadas à computação, um ajuste de escala dinâmico permite que as workloads respondam automaticamente às mudanças e usem o conjunto ideal de recursos computacionais para atingir sua meta. 

 Você pode usar diversas abordagens diferentes para corresponder a oferta de recursos com a demanda. 
+  **Abordagem de monitoramento de meta**: monitore a métrica de ajuste de escala e aumente ou diminua automaticamente a capacidade conforme necessário. 
+  **Ajuste de escala preditivo**: reduza a escala horizontalmente em antecipação às tendências diárias e semanais. 
+  **Abordagem baseada em cronograma**: defina seu próprio cronograma de escalabilidade de acordo com as mudanças de carga previsíveis. 
+  **Escalabilidade de serviços**: escolha serviços (como de tecnologia sem servidor) que sejam escalados automaticamente de acordo com o projeto. 

 É necessário garantir que as implantações de carga de trabalho possam lidar com eventos de expansão e redução da escala. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Instâncias, contêineres e funções de computação oferecem mecanismos para elasticidade, seja em combinação com o ajuste de escala automático ou como um recurso do serviço. Veja alguns exemplos de mecanismos de ajuste de escala automático:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_compute_hardware_scale_compute_resources_dynamically.html)
+  O ajuste de escala geralmente é discutido em relação a serviços de computação, como instâncias do Amazon EC2 ou funções do AWS Lambda. Não se esqueça de pensar também na configuração de serviços não computacionais, como [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/auto-scaling.html) para atender à demanda. 
+  Verifique se as métricas de ajuste de escala correspondem às características da workload que está sendo implantada. Se você estiver implantando uma aplicação de transcodificação de vídeo, espera-se que a utilização da CPU seja de 100%, e essa não deve ser sua métrica principal. Em vez disso, use a profundidade da fila de trabalhos de transcodificação. Você pode usar uma [métrica personalizada](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) para a política de escalabilidade, se necessário. Para escolher as métricas certas, considere a seguinte orientação para o Amazon EC2: 
  +  A métrica deve ser uma métrica de utilização válida e descrever o quanto uma instância está ocupada. 
  +  O valor da métrica deve aumentar ou diminuir proporcionalmente com o número de instâncias no grupo do Auto Scaling. 
+  Use [a escalabilidade dinâmica](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html) em vez de [escalabilidade manual](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) para seu grupo do Auto Scaling. Também recomendamos que você use [políticas de escalabilidade de monitoramento do objetivo](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) em sua escalabilidade dinâmica. 
+  Verifique se as implantações da workload podem lidar com os dois eventos de ajuste de escala (aumento e redução). Por exemplo, você pode usar o [histórico de atividades](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html) para verificar uma atividade de escalabilidade para um grupo do Auto Scaling. 
+  Avalie sua workload com relação a padrões previsíveis e, ao antecipar alterações previstas e planejadas na demanda, escale proativamente. Com a escalabilidade preditiva, é possível eliminar a necessidade de superprovisionar a capacidade. Para obter mais detalhes, consulte [Ajuste de escala com o Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Cloud Compute with AWS](https://aws.amazon.com/products/compute/) 
+  [Amazon EC2 Instance Types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) 
+  [Amazon ECS Containers: Amazon ECS Container Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html) 
+  [Amazon EKS Containers: Amazon EKS Worker Nodes](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) 
+  [Funções: configuração de função do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) 
+  [Processor State Control for Your Amazon EC2 Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html) 
+  [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/) 
+  [Introducing Karpenter – An Open-Source High-Performance Kubernetes Cluster Autoscaler (Apresentação do Karpenter: um dimensionador automático de clusters do Kubernetes de código aberto e alto desempenho)](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/) 

 **Vídeos relacionados:** 
+  [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2](https://www.youtube.com/watch?v=_dvh4P2FVbw) 
+  [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4) 
+  [Criar um ambiente de computação eficiente em termos de custo, energia e recursos](https://www.youtube.com/watch?v=8zsC5e1eLCg) 

 **Exemplos relacionados:** 
+  [Amazon EC2 Auto Scaling Group Examples](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) 
+  [Implement Autoscaling with Karpenter](https://www.eksworkshop.com/beginner/085_scaling_karpenter/) 

# PERF02-BP06 Use optimized hardware-based compute accelerators
<a name="perf_compute_hardware_compute_accelerators"></a>

 Use aceleradores de hardware para executar determinadas funções com mais eficiência do que as alternativas baseadas em CPU. 

 **Antipadrões comuns:** 
+  Em sua workload, você não compara uma instância de uso geral com uma instância criada para um propósito específico que possa oferecer maior desempenho e menor custo. 
+  Você está usando aceleradores de computação baseados em hardware para tarefas que podem ser mais eficientes usando alternativas baseadas em CPU. 
+  Você não está monitorando o uso da GPU. 

**Benefícios de estabelecer esta prática recomendada:** Ao usar aceleradores baseados em hardware, como unidades de processamento gráfico (GPUs) e matrizes de portas programáveis em campo (FPGAs), você pode executar determinadas funções de processamento com mais eficiência. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 As instâncias com computação acelerada fornecem acesso a aceleradores de computação baseados em hardware, como GPUs e FPGAs. Esses aceleradores de hardware executam certas funções, como processamento gráfico ou correspondência de padrões de dados, com mais eficiência do que alternativas baseadas em CPU. Muitas workloads aceleradas, como renderização, transcodificação e machine learning, são altamente variáveis em termos de uso de recursos. Execute esse hardware apenas pelo tempo necessário e desative-as com automação quando não precisar mais delas para melhorar a eficiência geral do desempenho. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Identifique quais [instâncias com computação acelerada](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html) podem atender aos seus requisitos. 
+  Para workloads de machine learning, utilize hardware específico para sua workload, como [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)e o [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/). Instâncias do AWS Inferentia, como instâncias Inf2, [oferecem até 50% melhor performance/watt em relação a instâncias comparáveis do Amazon EC2](https://aws.amazon.com/machine-learning/inferentia/). 
+  Colete métricas de uso para as instâncias com computação acelerada. Por exemplo, você pode usar o agente do CloudWatch para coletar métricas como `utilization_gpu` e `utilization_memory` para suas GPUs, conforme mostrado em [Colete métricas da GPU NVIDIA com o Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html). 
+  Otimize o código, a operação de rede e as configurações dos aceleradores de hardware para garantir que o hardware subjacente seja totalmente utilizado. 
  +  [Otimizar as configurações da GPU](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/optimize_gpu.html) 
  +  [Monitoramento e otimização de GPU no Deep Learning AMI](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-gpu.html) 
  +  [Otimização de E/S para ajuste de desempenho de GPU de treinamento de aprendizado profundo no Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/optimizing-i-o-for-gpu-performance-tuning-of-deep-learning-training-in-amazon-sagemaker/) 
+  Use as mais recentes bibliotecas de alto desempenho e drivers de GPU. 
+  Use automação para liberar instâncias de GPU quando não estiverem em uso. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Instâncias de GPU](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html#gpu-instances) 
+  [Instâncias com AWS Trainium](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html#aws-trainium-instances) 
+  [Instâncias com o AWS Inferentia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html#aws-inferentia-instances) 
+  [Let’s Architect\$1 Arquitetura com chips e aceleradores personalizados](https://aws.amazon.com/blogs/architecture/lets-architect-custom-chips-and-accelerators/) 
+  [Computação acelerada](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing) 
+  [Instâncias VT1 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/vt1/) 
+  [Como faço para escolher o tipo de instância do Amazon EC2 apropriado para minha workload?](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/) 
+  [Escolha o melhor acelerador de IA e compilação de modelo para inferência de visão computacional com o Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/choose-the-best-ai-accelerator-and-model-compilation-for-computer-vision-inference-with-amazon-sagemaker/) 

 **Vídeos relacionados:** 
+  [How to select Amazon EC2 GPU instances for deep learning (Como selecionar instâncias de GPU do Amazon EC2 para aprendizado profundo)](https://www.youtube.com/watch?v=4bVrIbgGWEA&ab_channel=AWSEvents) 
+  [Deploying Cost-Effective Deep Learning Inference (Implantação de inferência de aprendizado profundo econômico)](https://www.youtube.com/watch?v=WiCougIDRsw&ab_channel=AWSOnlineTechTalks) 

# Gerenciamento de dados
<a name="a-data-management"></a>

# PERFORMANCE 3. Como você armazena, gerencia e acessa dados em sua workload?
<a name="perf-03"></a>

 A solução de gerenciamento de dados ideal para um sistema específico varia conforme o tipo de dados (bloco, arquivo ou objeto), os padrões de acesso (aleatório ou sequencial), o throughput necessário, a frequência de acesso (online, offline, arquivamento), a frequência de atualização (WORM, dinâmica) e as restrições de disponibilidade e durabilidade. As workloads do Well-Architected usam datastores específicos que permitem que recursos diferentes melhorem o desempenho. 

**Topics**
+ [PERF03-BP01 Use um armazenamento de dados específico que melhor atenda aos seus requisitos de acesso e armazenamento de dados](perf_data_use_purpose_built_data_store.md)
+ [PERF03-BP02 Avalie as opções de configuração disponíveis para o datastore](perf_data_evaluate_configuration_options_data_store.md)
+ [PERF03-BP03 Colete e registre métricas de desempenho do datastore](perf_data_collect_record_data_store_performance_metrics.md)
+ [PERF03-BP04 Implemente estratégias para melhorar o desempenho da consulta no datastore](perf_data_implement_strategies_to_improve_query_performance.md)
+ [PERF03-BP05 Implementar padrões de acesso a dados que utilizem cache](perf_data_access_patterns_caching.md)

# PERF03-BP01 Use um armazenamento de dados específico que melhor atenda aos seus requisitos de acesso e armazenamento de dados
<a name="perf_data_use_purpose_built_data_store"></a>

 Entenda as características dos dados (como possibilidade de compartilhamento, tamanho, tamanho do cache, padrões de acesso, latência, throughput e persistência dos dados) a fim de selecionar os datastores com propósito específico (armazenamento ou banco de dados) para sua workload. 

 **Antipadrões comuns:** 
+  Fixar-se em um único datastore porque há experiência e conhecimento internos de um tipo específico de solução de banco de dados. 
+  Você pressupõe que todas as workloads têm requisitos de acesso e armazenamento de dados semelhantes. 
+  Você não implementou um catálogo de dados para criar um inventário de seus ativos de dados. 

 **Benefícios de estabelecer esta prática recomendada:** Entender as características e os requisitos de dados permite que você determine a tecnologia de armazenamento mais eficiente e com melhor performance, adequada às necessidades da workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Ao selecionar e implementar o armazenamento de dados, certifique-se de que as características de consulta, ajuste de escala e armazenamento atendam aos requisitos de dados da workload. A AWS fornece várias tecnologias de armazenamento de dados e banco de dados, incluindo armazenamento em blocos, armazenamento de objetos, armazenamento de streaming, sistema de arquivos, bancos de dados relacionais, de chave-valor, de documentos, na memória, de grafos, de séries temporais e ledger. Cada solução de gerenciamento de dados tem opções e configurações disponíveis para compatibilidade com seus casos de uso e modelos de dados. Ao compreender as características e os requisitos dos dados, você pode se separar da tecnologia de armazenamento monolítico e das abordagens restritivas e únicas para se concentrar no gerenciamento adequado dos dados. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Realize um inventário dos vários tipos de dados que existem na workload. 
+  Entenda e documente as características e os requisitos dos dados, incluindo: 
  +  Tipo de dados (não estruturados, semiestruturados, relacionais) 
  +  Volume e crescimento de dados 
  +  Durabilidade dos dados: persistentes, efêmeros, transitórios 
  +  Requisitos de ACID (atomicidade, consistência, isolamento, durabilidade) 
  +  Padrões de acesso a dados (com muita leitura ou gravação) 
  +  Latência 
  +  Taxa de transferência 
  +  IOPS (operações de entrada/saída por segundo) 
  +  Período de retenção de dados 
+  Conheça os diferentes datastores disponíveis para a workload na AWS que podem atender às características dos dados (conforme descrito em [PERF01-BP01 Conheça e compreenda os serviços e recursos de nuvem disponíveis](perf_architecture_understand_cloud_services_and_features.md)). Alguns exemplos de tecnologias de armazenamento da AWS e suas principais características incluem:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_data_use_purpose_built_data_store.html)
+  Se você estiver criando uma plataforma de dados, utilize uma [arquitetura de dados moderna](https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/) na AWS para integrar data lake, data warehouse e armazenamentos de dados com propósito específico. 
+  As principais questões que você precisa considerar ao escolher um datastore para sua workload são as seguintes:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_data_use_purpose_built_data_store.html)
+  Faça experimentos e testes comparativos em um ambiente que não seja de produção para identificar qual datastore pode atender às necessidades da workload. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Tipos de volume do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) 
+  [Armazenamento do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html) 
+  [Amazon EFS: performance do Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/performance.html) 
+  [Performance do Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html) 
+  [Performance do Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/performance.html) 
+  [Documentação do Amazon Glacier: Amazon Glacier](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html) 
+  [Amazon S3: considerações sobre performance e taxa de solicitação](https://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html) 
+  [Armazenamento na nuvem com a AWS](https://aws.amazon.com/products/storage/) 
+  [Características de E/S do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html) 
+  [Bancos de dados em nuvem com a AWS ](https://aws.amazon.com/products/databases/?ref=wellarchitected) 
+  [Armazenamento em cache de banco de dados da AWS ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) 
+  [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/?ref=wellarchitected) 
+  [Práticas recomendadas do Amazon Aurora ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected) 
+  [Performance do Amazon Redshift ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected) 
+  [10 melhores dicas de desempenho do Amazon Athena ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected) 
+  [Práticas recomendadas do Amazon Redshift Spectrum ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/?ref=wellarchitected) 
+  [Melhores práticas do Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html?ref=wellarchitected) 
+  [Choose between Amazon EC2 and Amazon RDS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/comparison.html) 
+ [ Melhores práticas para a implementação do Amazon ElastiCache ](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/BestPractices.html)

 **Vídeos relacionados:** 
+  [Deep dive on Amazon EBS](https://www.youtube.com/watch?v=wsMWANWNoqQ) 
+  [Optimize your storage performance with Amazon S3](https://www.youtube.com/watch?v=54AhwfME6wI) 
+ [Modernize apps with purpose-built databases](https://www.youtube.com/watch?v=V-DiplATdi0)
+ [ Amazon Aurora storage demystified: How it all works ](https://www.youtube.com/watch?v=uaQEGLKtw54)
+ [ Amazon DynamoDB deep dive: Advanced design patterns ](https://www.youtube.com/watch?v=6yqfmXiZTlM)

 **Exemplos relacionados:** 
+  [Driver CSI do Amazon EFS](https://github.com/kubernetes-sigs/aws-efs-csi-driver) 
+  [Driver CSI do Amazon EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) 
+  [Utilitários do Amazon EFS](https://github.com/aws/efs-utils) 
+  [Escalabilidade automática do Amazon EBS](https://github.com/awslabs/amazon-ebs-autoscale) 
+  [Exemplos do Amazon S3](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html) 
+  [Optimize Data Pattern using Amazon Redshift Data Sharing](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/) 
+  [Migrações de bancos de dados](https://github.com/aws-samples/aws-database-migration-samples) 
+  [MS SQL Server - AWS Database Migration Service (AWS DMS) Replication Demo](https://github.com/aws-samples/aws-dms-sql-server) 
+  [Database Modernization Hands On Workshop (Workshop prático de modernização de bancos de dados)](https://github.com/aws-samples/amazon-rds-purpose-built-workshop) 
+  [Amostras da Amazon Neptune](https://github.com/aws-samples/amazon-neptune-samples) 

# PERF03-BP02 Avalie as opções de configuração disponíveis para o datastore
<a name="perf_data_evaluate_configuration_options_data_store"></a>

 Entenda e avalie os vários atributos e opções de configuração disponíveis para seus datastores a fim de otimizar o espaço de armazenamento e o desempenho da workload. 

 **Antipadrões comuns:** 
+  Você só usa um tipo de armazenamento, como o Amazon EBS, para todas as workloads. 
+  Você usa as IOPS provisionadas para todas as workloads sem testes reais em todos os níveis de armazenamento. 
+  Você não tem ciência das opções de configuração da solução de gerenciamento de dados escolhida. 
+  Você conta somente com o aumento do tamanho da instância sem examinar outras opções de configuração. 
+  Você não testa as características de ajuste de escala do datastore. 

 **Benefícios de estabelecer esta prática recomendada:** A exploração e a experimentação das configurações de datastore permitem que você reduza o custo da infraestrutura, melhore a performance e diminua o esforço necessário para manter as workloads. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Uma workload pode ter um ou mais datastores usados com base nos requisitos de armazenamento e acesso aos dados. Para otimizar a eficiência e o custo do desempenho, você deve avaliar os padrões de acesso aos dados para determinar as configurações apropriadas do datastore. Ao explorar as opções de datastore, leve em consideração vários aspectos, como opções de armazenamento, memória, computação, réplica de leitura, requisitos de consistência, grupo de conexões e opções de armazenamento em cache. Experimente essas várias opções de configuração para melhorar as métricas de eficiência do desempenho. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Entenda as configurações atuais (como tipo de instância, tamanho do armazenamento ou versão do mecanismo de banco de dados) do datastore. 
+  Analise a documentação da AWS e as práticas recomendadas para saber mais sobre as opções de configuração indicadas que podem ajudar a melhorar o desempenho do datastore. As principais opções de datastore a serem consideradas são as seguintes:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_data_evaluate_configuration_options_data_store.html)
+  Realize experimentos e testes comparativos em um ambiente que não seja de produção para identificar qual opção de configuração pode atender aos requisitos da workload. 
+  Depois de experimentar, planeje a migração e valide as métricas de desempenho. 
+  Use ferramentas de monitoramento da AWS (como o [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)) e otimização (como a [Lente de Armazenamento do Amazon S3](https://aws.amazon.com/s3/storage-lens/)) para otimizar continuamente o armazenamento de dados usando o padrão de uso do mundo real. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Armazenamento na nuvem com a AWS](https://aws.amazon.com/products/storage/?ref=wellarchitected) 
+  [Tipos de volume do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) 
+  [Armazenamento do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html) 
+  [Amazon EFS: performance do Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/performance.html) 
+  [Performance do Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html) 
+  [Performance do Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/performance.html) 
+  [Documentação do Amazon Glacier: Amazon Glacier](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html) 
+  [Amazon S3: considerações sobre performance e taxa de solicitação](https://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html) 
+  [Armazenamento na nuvem com a AWS](https://aws.amazon.com/products/storage/) 
+  [Armazenamento na nuvem com a AWS](https://aws.amazon.com/products/storage/?ref=wellarchitected) 
+  [Características de E/S do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html) 
+  [Bancos de dados em nuvem com a AWS ](https://aws.amazon.com/products/databases/?ref=wellarchitected) 
+  [Armazenamento em cache de banco de dados da AWS ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) 
+  [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/?ref=wellarchitected) 
+  [Práticas recomendadas do Amazon Aurora ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected) 
+  [Performance do Amazon Redshift ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected) 
+  [10 melhores dicas de desempenho do Amazon Athena ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected) 
+  [Práticas recomendadas do Amazon Redshift Spectrum ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/?ref=wellarchitected) 
+  [Melhores práticas do Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html?ref=wellarchitected) 

 **Vídeos relacionados:** 
+  [Deep dive on Amazon EBS](https://www.youtube.com/watch?v=wsMWANWNoqQ) 
+  [Optimize your storage performance with Amazon S3](https://www.youtube.com/watch?v=54AhwfME6wI) 
+ [Modernize apps with purpose-built databases](https://www.youtube.com/watch?v=V-DiplATdi0)
+ [ Amazon Aurora storage demystified: How it all works ](https://www.youtube.com/watch?v=uaQEGLKtw54)
+ [ Amazon DynamoDB deep dive: Advanced design patterns ](https://www.youtube.com/watch?v=6yqfmXiZTlM)

 **Exemplos relacionados:** 
+  [Driver CSI do Amazon EFS](https://github.com/kubernetes-sigs/aws-efs-csi-driver) 
+  [Driver CSI do Amazon EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) 
+  [Utilitários do Amazon EFS](https://github.com/aws/efs-utils) 
+  [Escalabilidade automática do Amazon EBS](https://github.com/awslabs/amazon-ebs-autoscale) 
+  [Exemplos do Amazon S3](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html) 
+  [Exemplos do Amazon DynamoDB](https://github.com/aws-samples/aws-dynamodb-examples) 
+  [AWS Database migration samples](https://github.com/aws-samples/aws-database-migration-samples) 
+  [Database Modernization Workshop (Workshop de modernização de bancos de dados)](https://github.com/aws-samples/amazon-rds-purpose-built-workshop) 
+  [Working with parameters on your Amazon RDS for Postgress DB](https://github.com/awsdocs/amazon-rds-user-guide/blob/main/doc_source/Appendix.PostgreSQL.CommonDBATasks.Parameters.md) 

# PERF03-BP03 Colete e registre métricas de desempenho do datastore
<a name="perf_data_collect_record_data_store_performance_metrics"></a>

 Acompanhe e registre métricas de desempenho relevantes para o datastore a fim de entender o desempenho de suas soluções de gerenciamento de dados. Essas métricas podem ajudar você a otimizar o datastore, verificar se os requisitos da workload foram atendidos e fornecer uma visão geral clara do desempenho da workload. 

 **Antipadrões comuns:** 
+  Você só usa a pesquisa manual de arquivos de log para métricas. 
+  Você só publica métricas em ferramentas internas usadas pela equipe e não tem uma imagem abrangente da workload. 
+  Você só usa as métricas comuns registradas pelo software de monitoramento selecionado. 
+  Você só revisa as métricas quando há um problema. 
+  Você só monitora as métricas no sistema e não captura as métricas de uso e acesso aos dados. 

 **Benefícios de estabelecer esta prática recomendada:** O estabelecimento de uma linha de base de performance ajuda a compreender o comportamento normal e os requisitos das workloads. Padrões anormais podem ser identificados e depurados mais rapidamente, melhorando a performance e a confiabilidade do datastore. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Para monitorar a performance dos datastores, você precisa registrar várias métricas de desempenho ao longo de um período. Isso permite detectar anomalias e avaliar o desempenho em relação às métricas de negócios para verificar se as necessidades da workload estão sendo atendidas. 

 As métricas devem incluir as do sistema subjacente que oferece suporte ao datastore e as do banco de dados. As métricas do sistema subjacente podem incluir métricas de utilização de CPU, memória, armazenamento em disco disponível, E/S de disco, taxa de acertos do cache e entrada e saída da rede, enquanto as métricas do datastore devem incluir transações por segundo, tempos de resposta, uso de índice, bloqueios de tabela, tempos limite de consultas e número de conexões abertas. Esses dados são essenciais para compreender como está a performance da workload e como a solução de gerenciamento de dados é usada. Use essas métricas como parte de uma abordagem orientada por dados para ajustar e otimizar os recursos da workload.  

 Use ferramentas, bibliotecas e sistemas que registram as medidas de performance relacionadas ao banco de dados. 

## Etapas da implementação
<a name="implementation-steps"></a>

1.  Identifique as principais métricas de desempenho que o datastore deve monitorar. 

   1.  [Métricas e dimensões do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/metrics-dimensions.html) 

   1.  [Métricas de monitoramento para em uma instância do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) 

   1.  [Monitorar a carga do banco de dados com o Performance Insights no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 

   1.  [Visão geral do monitoramento aprimorado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.overview.html) 

   1.  [Métricas e dimensões do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html) 

   1.  [Monitoramento do DynamoDB Accelerator](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.Monitoring.html) 

   1.  [Monitoramento do Amazon MemoryDB com o Amazon CloudWatch](https://docs.aws.amazon.com/memorydb/latest/devguide/monitoring-cloudwatch.html) 

   1.  [Quais métricas devo monitorar?](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html) 

   1.  [Monitoramento da performance do cluster do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/metrics.html) 

   1.  [Métricas e dimensões do Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/metrics-dimensions.html) 

   1.  [Métricas do Amazon CloudWatch para Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html) 

   1.  [Registro em log e monitoramento no Amazon Keyspaces (for Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/monitoring.html) 

   1.  [Monitoramento dos recursos do Amazon Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/monitoring.html) 

1.  Use uma solução aprovada de registro em log e monitoramento para coletar essas métricas. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) pode coletar métricas nos recursos na sua arquitetura. Você também pode coletar e publicar métricas personalizadas para descobrir métricas de negócio ou derivadas. Use o CloudWatch ou soluções de terceiros para definir alarmes que indiquem quando os limites são violados. 

1.  Confira se o monitoramento do datastore pode se beneficiar de uma solução de machine learning que detecta anomalias de performance. 

   1.  [O Amazon DevOps Guru para Amazon RDS](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-rds.overview.how-it-works.html) fornece visibilidade dos problemas de performance e faz recomendações de ações corretivas. 

1.  Configure a retenção de dados em sua solução de monitoramento e registro para corresponder às suas metas operacionais e de segurança. 

   1.  [Retenção de dados padrão para métricas do CloudWatch](https://aws.amazon.com/cloudwatch/faqs/#AWS_resource_.26_custom_metrics_monitoring) 

   1.  [Retenção de dados padrão para o CloudWatch Logs](https://aws.amazon.com/cloudwatch/faqs/#Log_management) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Armazenamento em cache de banco de dados da AWS](https://aws.amazon.com/caching/database-caching/) 
+  [10 melhores dicas de desempenho do Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) 
+  [Práticas recomendadas do Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html) 
+  [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/) 
+  [Melhores práticas do Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html) 
+  [Práticas recomendadas do Amazon Redshift Spectrum](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/) 
+  [Performance do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html) 
+  [Bancos de dados em nuvem com a AWS](https://aws.amazon.com/products/databases/) 
+  [Insights de performance do Amazon RDS](https://aws.amazon.com/rds/performance-insights/) 

 **Vídeos relacionados:** 
+  [AWS purpose-built databases](https://www.youtube.com/watch?v=q81TVuV5u28) 
+  [Amazon Aurora storage demystified: How it all works](https://www.youtube.com/watch?v=uaQEGLKtw54) 
+  [Amazon DynamoDB deep dive: Advanced design patterns](https://www.youtube.com/watch?v=6yqfmXiZTlM) 
+  [Best Practices for Monitoring Redis Workloads on Amazon ElastiCache](https://www.youtube.com/watch?v=c-hTMLN35BY&ab_channel=AWSOnlineTechTalks) 

 **Exemplos relacionados:** 
+  [Level 100: Monitoring with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) 
+  [AWS Dataset Ingestion Metrics Collection Framework](https://github.com/awslabs/aws-dataset-ingestion-metrics-collection-framework) 
+  [Amazon RDS Monitoring Workshop](https://www.workshops.aws/?tag=Enhanced%20Monitoring) 

# PERF03-BP04 Implemente estratégias para melhorar o desempenho da consulta no datastore
<a name="perf_data_implement_strategies_to_improve_query_performance"></a>

 Implemente estratégias para otimizar os dados e melhorar a consulta de dados a fim de permitir mais escalabilidade e desempenho eficiente para a workload. 

 **Antipadrões comuns:** 
+  Você não particiona dados no datastore. 
+  Você armazena dados em apenas um formato de arquivo no datastore. 
+  Você não usa índices no datastore. 

 **Benefícios de estabelecer esta prática recomendada:** A otimização da performance dos dados e das consultas ocasiona mais eficiência, menor custo e melhor experiência do usuário. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

A otimização de dados e o ajuste de consultas são aspectos essenciais da eficiência do desempenho em um datastore, pois afetam não só o desempenho como também a capacidade de resposta de toda a workload na nuvem. Consultas não otimizadas podem ocasionar maior uso de recursos e gargalos, o que reduz a eficiência geral de um datastore. 

A otimização de dados inclui várias técnicas para garantir o armazenamento e o acesso eficientes aos dados. Esse processo também ajuda a melhorar o desempenho da consulta em um datastore. As principais estratégias incluem particionamento, compactação e desnormalização de dados, que ajudam a otimizá-los para armazenamento e acesso.

### Etapas da implementação
<a name="implementation-steps"></a>
+  Entenda e analise as consultas críticas de dados que são realizadas no datastore. 
+  Identifique as consultas com execução lenta no datastore e use planos de consulta para entender o estado atual delas. 
  +  [Analyzing the query plan in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/c-analyzing-the-query-plan.html) 
  +  [Using EXPLAIN and EXPLAIN ANALYZE in Athena](https://docs.aws.amazon.com/athena/latest/ug/athena-explain-statement.html) 
+  Implemente estratégias para melhorar o desempenho da consulta. Algumas das principais estratégias incluem: 
  +  Usar um [formato de arquivo colunar](https://docs.aws.amazon.com/athena/latest/ug/columnar-storage.html) (como Parquet ou ORC). 
  + Compactar os dados no datastore para reduzir o espaço de armazenamento e a operação de E/S.
  +  Particionar os dados para dividi-los em partes menores e reduzir o tempo de verificação dos dados. 
    + [ Partitioning data in Athena ](https://docs.aws.amazon.com/athena/latest/ug/partitions.html)
    + [ Partições e distribuição de dados ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html)
  +  Indexação de dados nas colunas comuns na consulta. 
  +  Escolha a operação de junção correta para consulta. Ao unir duas tabelas, especifique a tabela maior no lado esquerdo da junção e a tabela menor no lado direito. 
  +  Solução de cache distribuído para melhorar a latência e reduzir o número de operações de E/S do banco de dados. 
  +  Manutenção regular, como execução de estatísticas. 
+  Experimente e teste estratégias em um ambiente que não seja de produção. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Práticas recomendadas do Amazon Aurora ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected) 
+  [Performance do Amazon Redshift ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected) 
+  [10 melhores dicas de desempenho do Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected) 
+  [Armazenamento em cache de banco de dados da AWS ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) 
+  [Melhores práticas para a implementação do Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/BestPractices.html) 
+  [Partitioning data in Athena](https://docs.aws.amazon.com/athena/latest/ug/partitions.html) 

 **Vídeos relacionados:** 
+  [Optimize Data Pattern using Amazon Redshift Data Sharing](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/) 
+  [Optimize Amazon Athena Queries with New Query Analysis Tools ](https://www.youtube.com/watch?v=7JUyTqglmNU&ab_channel=AmazonWebServices) 

 **Exemplos relacionados:** 
+  [Driver CSI do Amazon EFS](https://github.com/kubernetes-sigs/aws-efs-csi-driver) 

# PERF03-BP05 Implementar padrões de acesso a dados que utilizem cache
<a name="perf_data_access_patterns_caching"></a>

 Implemente padrões de acesso que possam se beneficiar do armazenamento em cache de dados para recuperação rápida de dados acessados com frequência. 

 **Antipadrões comuns:** 
+  Você armazena em cache dados que mudam com frequência. 
+  Você depende dos dados em cache como se estivessem armazenados de forma durável e sempre disponíveis. 
+  Você não leva em conta a consistência dos seus dados em cache. 
+  Você não monitora a eficiência da sua implementação de cache. 

 **Benefícios de estabelecer esta prática recomendada:** armazenar dados em um cache pode melhorar a latência de leitura, throughput de leitura, a experiência do usuário e a eficiência geral, além de reduzir custos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida**: médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Um cache é um componente de software ou hardware destinado a armazenar dados para que futuras solicitações dos mesmos dados possam ser atendidas com maior rapidez e eficiência. Os dados armazenados em um cache podem ser reconstruídos se perdidos, repetindo um cálculo anterior ou obtendo-os de outro armazenamento de dados. 

 O armazenamento de dados em cache pode ser uma das estratégias mais eficazes para melhorar o desempenho geral da aplicação e reduzir a carga sobre as fontes de dados primárias subjacentes. Os dados podem ser armazenados em cache em vários níveis na aplicação, tais como dentro da aplicação fazendo chamadas remotas, conhecidas como *armazenamento em cache do lado do cliente,*ou usando um serviço secundário rápido para armazenar os dados, conhecido como *armazenamento em cache remoto*. 

 **Armazenamento em cache do lado do cliente** 

 Com o armazenamento em cache do lado do cliente, cada cliente (uma aplicação ou serviço que consulta o datastore de back-end) pode armazenar os resultados de suas consultas exclusivas localmente por um período especificado. Isso pode reduzir o número de solicitações na rede para um datastore verificando primeiro o cache do cliente local. Se os resultados não estiverem presentes, a aplicação poderá então consultar o datastore e armazenar esses resultados localmente. Esse padrão permite que cada cliente armazene dados no local mais próximo (o próprio cliente), resultando na menor latência possível. Os clientes também podem continuar a atender algumas consultas quando o datastore de back-end não está disponível, aumentando a disponibilidade geral do sistema. 

 Uma desvantagem dessa abordagem é que, quando vários clientes estão envolvidos, eles podem armazenar os mesmos dados em cache localmente. Isso resulta no uso de armazenamento duplicado e na inconsistência de dados entre esses clientes. Um cliente pode armazenar em cache os resultados de uma consulta e, um minuto depois, outro cliente pode executar a mesma consulta e obter um resultado diferente. 

 **Armazenamento em cache remoto** 

 Para resolver o problema de dados duplicados entre clientes, um serviço externo rápido, ou *cache remoto,*pode ser usado para armazenar os dados consultados. Em vez de verificar um datastore local, cada cliente verificará o cache remoto antes de consultar o datastore de back-end. Essa estratégia permite respostas mais consistentes entre clientes, melhor eficiência nos dados armazenados e um volume maior de dados em cache, pois o espaço de armazenamento é dimensionado independentemente dos clientes. 

 A desvantagem de um cache remoto é que o sistema geral pode ter uma latência maior, pois é necessário um salto de rede adicional para verificar o cache remoto. O cache do lado do cliente pode ser usado junto com o armazenamento em cache remoto para o armazenamento em vários níveis para melhorar a latência. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Identifique bancos de dados, APIs e serviços de rede que poderiam se beneficiar do armazenamento em cache. Serviços que têm workloads de leitura pesadas, uma alta taxa de leitura e gravação ou que são caros para escalar são candidatos ao armazenamento em cache. 
   +  [Armazenamento em cache de banco de dados](https://aws.amazon.com/caching/database-caching/) 
   +  [Ativação do armazenamento em cache da API para melhorar a capacidade de resposta](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html) 

1.  Identifique o tipo apropriado de estratégia de armazenamento em cache que melhor se adapte ao seu padrão de acesso. 
   +  [Estratégias de armazenamento em cache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Strategies.html) 
   +  [Soluções de armazenamento em cache da AWS](https://aws.amazon.com/caching/aws-caching/) 

1.  Siga [Práticas recomendadas de armazenamento em cache](https://aws.amazon.com/caching/best-practices/) para seu armazenamento de dados. 

1.  Configure uma estratégia de invalidação de cache, como um time-to-live (TTL), para todos os dados que equilibre a atualização dos dados e reduza a pressão sobre o datastore de back-end. 

1.  Ative recursos como novas tentativas automáticas de conexão, recuo exponencial, tempos limite do lado do cliente e pool de conexões no cliente, se disponíveis, pois eles podem melhorar o desempenho e a confiabilidade. 
   +  [Práticas recomendadas: clientes Redis e Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) 

1.  Monitore a taxa de acertos de cache com uma meta de 80% ou mais. Valores mais baixos podem indicar tamanho insuficiente do cache ou um padrão de acesso que não se beneficia do armazenamento em cache. 
   +  [Quais métricas devo monitorar?](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html) 
   +  [Práticas recomendadas para monitorar workloads do Redis no Amazon ElastiCache](https://www.youtube.com/watch?v=c-hTMLN35BY) 
   +  [Monitoramento das práticas recomendadas com Amazon ElastiCache (Redis OSS) usando o Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/) 

1.  Implemente [replicação de dados](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) para descarregar as leituras em várias instâncias e melhorar o desempenho e a disponibilidade da leitura de dados. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Uso do Amazon ElastiCache Well-Architected Lens](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WellArchitechtedLens.html) 
+  [Monitoramento das práticas recomendadas com Amazon ElastiCache (Redis OSS) usando o Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/) 
+  [Quais métricas devo monitorar?](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html) 
+  [Whitepaper: Performance at Scale with Amazon ElastiCache (Desempenho em escala com Amazon ElastiCache)](https://docs.aws.amazon.com/whitepapers/latest/scale-performance-elasticache/scale-performance-elasticache.html) 
+  [Desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 

 **Vídeos relacionados:** 
+  [Amazon ElastiCache Learning Path (Roteiro de aprendizado do Amazon ElastiCache)](https://pages.awscloud.com/GLB-WBNR-AWS-OTT-2021_LP_0003-DAT_AmazonElastiCache.html) 
+  [Design for success with Amazon ElastiCache best practices (Projete para o sucesso com as práticas recomendadas do Amazon ElastiCache)](https://youtu.be/_4SkEy6r-C4) 

 **Exemplos relacionados:** 
+  [Como aumentar o desempenho do banco de dados MySQL com Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/getting-started/hands-on/boosting-mysql-database-performance-with-amazon-elasticache-for-redis/) 

# Rede e entrega de conteúdo
<a name="a-networking-delivery"></a>

# PERFORMANCE 4. Como você seleciona e configura os recursos de rede em sua workload?
<a name="perf-04"></a>

 A solução de banco de dados mais eficaz para um sistema varia conforme os requisitos de disponibilidade, consistência, tolerância da partição, latência, durabilidade, escalabilidade e capacidade de consulta. Muitos sistemas usam soluções de banco de dados diferentes para vários subsistemas e acionam diferentes recursos para melhorar a performance. A seleção da solução e dos recursos de banco de dados incorretos para um sistema pode levar a uma menor performance do sistema. 

**Topics**
+ [PERF04-BP01 Compreender como as redes afetam a performance](perf_networking_understand_how_networking_impacts_performance.md)
+ [PERF04-BP02 Avaliar os recursos de redes disponíveis](perf_networking_evaluate_networking_features.md)
+ [PERF04-BP03 Escolher a conectividade dedicada ou VPN apropriada para a workload](perf_networking_choose_appropriate_dedicated_connectivity_or_vpn.md)
+ [PERF04-BP04 Usar o balanceamento de carga para distribuir o tráfego em vários recursos](perf_networking_load_balancing_distribute_traffic.md)
+ [PERF04-BP05 Escolher os protocolos de rede para melhorar o desempenho](perf_networking_choose_network_protocols_improve_performance.md)
+ [PERF04-BP06 Escolher o local da workload com base nos requisitos de rede](perf_networking_choose_workload_location_network_requirements.md)
+ [PERF04-BP07 Otimizar a configuração da rede com base em métricas](perf_networking_optimize_network_configuration_based_on_metrics.md)

# PERF04-BP01 Compreender como as redes afetam a performance
<a name="perf_networking_understand_how_networking_impacts_performance"></a>

 Analise e entenda como as decisões relacionadas à rede afetam sua workload para fornecer desempenho eficiente e melhor experiência do usuário. 

 **Antipadrões comuns:** 
+  Todo o tráfego flui por meio dos datacenters existentes. 
+  Você direciona todo o tráfego por meio de firewalls centrais em vez de usar ferramentas de segurança de rede nativas da nuvem. 
+  Você provisiona conexões do AWS Direct Connect sem entender os requisitos reais de uso. 
+  Você não considera as características da workload e a sobrecarga da criptografia ao definir suas soluções de redes. 
+  Você usa conceitos e estratégias de on-premises para soluções de redes na nuvem. 

 **Benefícios de estabelecer esta prática recomendada:** a compreensão de como as redes afetam a performance da workload ajuda a identificar gargalos potenciais, a melhorar a experiência dos usuários, a aumentar a confiabilidade e a reduzir a manutenção operacional à medida que a workload muda. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A rede é responsável pela conectividade entre os componentes da aplicação, os serviços de nuvem, as redes de borda e os dados on-premises, portanto ela pode afetar significativamente a performance da workload. Além da performance da workload, a experiência dos usuários também é afetada pela latência da rede, a largura de banda, os protocolos, a localização, a congestão da rede, a variação de latência (jitter), o throughput e as regras de roteamento. 

 Ter uma lista documentada dos requisitos de rede da workload, incluindo latência, tamanho de pacotes, regras de roteamento, protocolos e padrões de tráfego compatíveis. Analise as soluções de redes disponíveis e identifique os serviços que atendem às características de redes da sua workload. É possível recriar as redes baseadas na nuvem rapidamente, portanto, é necessário evoluir sua arquitetura de rede ao longo do tempo para melhorar a eficiência da performance. 

### Etapas da implementação:
<a name="implementation-steps"></a>

1.  Defina e documente os requisitos de desempenho da rede, incluindo métricas como latência da rede, largura de banda, protocolos, locais, padrões de tráfego (picos e frequência), throughput, criptografia, inspeção e regras de roteamento. 

1.  Saiba mais sobre os principais serviços de rede da AWS, como [VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html), [O AWS Direct Connect](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect.html), [Elastic Load Balancing (ELB)](https://aws.amazon.com/elasticloadbalancing/) e [Amazon Route 53](https://aws.amazon.com/r53/). 

1.  Capture as seguintes características principais de rede:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_networking_understand_how_networking_impacts_performance.html)

1.  Realize o teste comparativo e de performance da rede: 

   1.  [Realize o teste comparativo](https://aws.amazon.com/premiumsupport/knowledge-center/network-throughput-benchmark-linux-ec2/) do throughput da rede, pois alguns fatores podem afetar o desempenho da rede do Amazon EC2 quando as instâncias estão na mesma VPC. Meça a largura de banda da rede entre as instâncias do Amazon EC2 Linux na mesma VPC. 

   1.  Execute [testes de carga](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) para experimentar soluções e opções de redes. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
+  [Rede avançada do EC2 no Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html) 
+  [Rede avançada do EC2 no Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking.html) 
+  [Grupos de posicionamento do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) 
+  [Como habilitar a rede avançada com o Adaptador de Rede Elástica (ENA) em instâncias Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) 
+  [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
+  [Produtos de redes com a AWS](https://aws.amazon.com/products/networking/) 
+  [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw) 
+  [Fazer a transição para o encaminhamento por latência no Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html) 
+  [Endpoints da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) 
+  [Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 

 **Vídeos relacionados:** 
+  [Connectivity to AWS and hybrid AWS network architectures (Conectividade com a AWS e arquiteturas de rede híbrida da AWS)](https://www.youtube.com/watch?v=eqW6CPb58gs) 
+  [Optimizing Network Performance for Amazon EC2 Instances (Otimização da performance da rede para instâncias do Amazon EC2)](https://www.youtube.com/watch?v=DWiwuYtIgu0) 
+  [Improve Global Network Performance for Applications (Melhorar a performance da rede global para aplicações)](https://youtu.be/vNIALfLTW9M) 
+  [EC2 Instances and Performance Optimization Best Practices (Práticas recomendadas para instâncias do EC2 e otimização da performance)](https://youtu.be/W0PKclqP3U0) 
+  [Optimizing Network Performance for Amazon EC2 Instances (Otimização da performance da rede para instâncias do Amazon EC2)](https://youtu.be/DWiwuYtIgu0) 
+  [Networking best practices and tips with the Well-Architected Framework (Práticas recomendadas e dicas de redes com o Well-Architected Framework)](https://youtu.be/wOMNpG49BeM) 
+  [AWS networking best practices in large-scale migrations (Práticas recomendadas da AWS em migrações de grande escala)](https://youtu.be/qCQvwLBjcbs) 

 **Exemplos relacionados:** 
+  [AWS Transit Gateway e soluções de segurança escaláveis](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions) 
+  [Workshops de redes da AWS](https://networking.workshop.aws/) 

# PERF04-BP02 Avaliar os recursos de redes disponíveis
<a name="perf_networking_evaluate_networking_features"></a>

Avalie recursos de rede na nuvem que possam melhorar o desempenho. Meça o impacto desses recursos por meio de testes, métricas e análises. Por exemplo, aproveite os recursos de rede que estão disponíveis para reduzir a latência, a distância ou a instabilidade da rede.

 **Antipadrões comuns:** 
+ Você permanece em uma Região, pois é onde sua sede está fisicamente localizada.
+ Você usa firewalls em vez de grupos de segurança para filtrar o tráfego.
+ Você quebra o TLS para inspeção de tráfego em vez de confiar em grupos de segurança, políticas de endpoint e outras funcionalidades nativas da nuvem.
+ Você só usa segmentação baseada em sub-rede em vez de grupos de segurança.

 **Benefícios de estabelecer esta prática recomendada:** avaliar todos os recursos e opções de serviços pode aumentar a performance da workload, reduzir o custo da infraestrutura, diminuir o esforço necessário para manter sua workload e aumentar sua postura geral de segurança. É possível utilizar a espinha dorsal da AWS para garantir a experiência ideal de redes para os clientes. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A AWS oferece serviços como [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) e o [Amazon CloudFront](https://aws.amazon.com/cloudfront/) que podem ajudar a melhorar o desempenho da rede, enquanto a maioria dos serviços da AWS tem recursos de produto (como a [Aceleração de Transferências do Amazon S3)](https://aws.amazon.com/s3/transfer-acceleration/) para otimizar o tráfego de rede. 

 Analise quais opções de configuração de rede estão disponíveis e como elas poderiam afetar a workload. A otimização do desempenho depende da compreensão de como essas opções interagem com sua arquitetura e do impacto que elas terão no desempenho medido e na experiência do usuário. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Crie uma lista de componentes da workload. 
  +  Considere o uso de [Nuvem AWS WAN](https://aws.amazon.com/cloud-wan/) para criar, gerenciar e monitorar a rede da sua organização ao criar uma rede global unificada. 
  +  Monitore suas redes globais e centrais com [métricas do Amazon CloudWatch Logs](https://docs.aws.amazon.com/network-manager/latest/tgwnm/monitoring-cloudwatch-metrics.html). Utilize o [Amazon CloudWatch RUM](https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-cloudwatch-rum-applications-client-side-performance/), que fornece insights para ajudar a identificar, entender e aprimorar a experiência digital dos usuários. 
  +  Visualize a latência agregada da rede entre Regiões da AWS e Zonas de Disponibilidade, bem como dentro de cada Zona de Disponibilidade, usando [AWS Network Manager](https://aws.amazon.com/transit-gateway/network-manager/) para obter informações sobre como o desempenho da sua aplicação se relaciona com o desempenho da rede da AWS subjacente. 
  +  Use uma ferramenta de banco de dados de gerenciamento de configurações (CMDB) existente ou uma ferramenta como o [AWS Config](https://aws.amazon.com/config/) para criar um inventário de sua workload e como ela é configurada. 
+  Se for uma workload existente, identifique e documente a referência para suas métricas de performance, focando nos gargalos e nas áreas de melhoria. As métricas de rede associadas a performance vão variar de acordo com a workload com base nos requisitos comerciais e nas características da workload. Como ponto de partida, a análise dessas métricas pode ser importante para sua workload: largura de banda, latência, perda de pacotes, instabilidade da rede e retransmissões. 
+  Se a workload for nova, realize [testes de carga](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) para identificar gargalos de performance. 
+  Para os gargalos de performance que identificar, analise as opções de configuração para suas soluções a fim de identificar oportunidades de melhoria da performance. Confira as seguintes principais opções e recursos de rede:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_networking_evaluate_networking_features.html)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [Instâncias otimizadas para Amazon EBS ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)
+ [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Rede avançada do EC2 no Linux ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html)
+ [Rede avançada do EC2 no Windows ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking.html)
+ [Grupos de posicionamento do EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
+ [Como habilitar a rede avançada com o Adaptador de Rede Elástica (ENA) em instâncias Linux ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html)
+ [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [Produtos de redes com a AWS](https://aws.amazon.com/products/networking/)
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Fazer a transição para o roteamento baseado em latência no Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html)
+ [VPC Endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html)
+ [Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)

 **Vídeos relacionados:** 
+ [Connectivity to AWS and hybrid AWS network architectures (Conectividade com a AWS e arquiteturas de rede híbrida da AWS)](https://www.youtube.com/watch?v=eqW6CPb58gs)
+ [Optimizing Network Performance for Amazon EC2 Instances (Otimização da performance da rede para instâncias do Amazon EC2)](https://www.youtube.com/watch?v=DWiwuYtIgu0)
+ [AWS Global Accelerator](https://www.youtube.com/watch?v=Docl4julOQw)

 **Exemplos relacionados:** 
+ [AWS Transit Gateway e soluções de segurança escaláveis ](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions)
+ [Workshops de redes da AWS](https://catalog.workshops.aws/networking/en-US)

# PERF04-BP03 Escolher a conectividade dedicada ou VPN apropriada para a workload
<a name="perf_networking_choose_appropriate_dedicated_connectivity_or_vpn"></a>

 Quando a conectividade híbrida é necessária para conectar recursos on-premises e na nuvem, provisione a largura de banda adequada para atender aos requisitos de performance. Estime os requisitos de largura de banda e de latência para a workload híbrida. Esses números determinarão seus requisitos de dimensionamento. 

 **Antipadrões comuns:** 
+  Você só avalia as soluções de VPN para seus requisitos de criptografia de rede. 
+  Você não avalia as opções de backup ou de conectividade redundante. 
+  Você não identifica todos os requisitos da workload (necessidades de criptografia, protocolo, largura de banda e tráfego). 

 **Benefícios de estabelecer esta prática recomendada:** Selecionar e configurar soluções de conectividade apropriadas aumentará a confiabilidade da workload e maximizará a performance. A identificação dos requisitos da workload, o planejamento antecipado e a avaliação das soluções híbridas podem minimizar alterações dispendiosas da rede física e despesas operacionais, e aumentará seu time-to-value. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Desenvolva uma arquitetura de rede híbrida com base em seus requisitos de largura de banda. [O Direct Connect](https://aws.amazon.com/directconnect/) permite que você conecte sua rede on-premises de forma privada com a AWS. Isso lhe dará segurança quando você precisar de largura de banda alta e baixa latência com uma performance consistente. Uma conexão VPN estabelece uma conexão segura pela internet. Ela é usada quando apenas uma conexão temporária é necessária, quando o custo é um fator ou como uma contingência enquanto se espera que uma conectividade de rede física resiliente seja estabelecida durante o uso do Direct Connect. 

 Se seus requisitos de largura de banda forem altos, considere vários serviços do Direct Connect ou de VPN. O tráfego pode ser balanceado entre os serviços, embora não recomendamos o balanceamento de carga entre o Direct Connect e a VPN devido às diferenças de latência e largura de banda. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Calcule os requisitos de largura de banda e latência de suas aplicações existentes. 

   1.  Para workloads existentes que estão sendo migradas para a AWS, utilize os dados de seus sistemas de monitoramento de rede internos. 

   1.  Para workloads novas ou existentes para as quais não há dados de monitoramento, consulte os proprietários do produto para determinar métricas de performance adequadas e fornecer uma experiência do usuário satisfatória. 

1.  Escolha uma conexão dedicada ou VPN como sua opção de conectividade. Com base em todos os requisitos da workload (necessidades de criptografia, largura de banda e tráfego), é possível escolher o AWS Direct Connect ou a [Site-to-Site VPN](https://aws.amazon.com/vpn/) (ou ambos). O diagrama a seguir ajudará você a escolher o tipo de conexão apropriada. 

   1.  [O AWS Direct Connect](https://aws.amazon.com/directconnect/) fornece conectividade dedicada ao ambiente da AWS, de 50 Mbps a 100 Gbps, usando conexões dedicadas ou conexões hospedadas. Isso permite que você tenha latência gerenciada e controlada, além de largura de banda provisionada para que a workload possa se conectar de forma eficiente com outros ambientes. Com os parceiros do AWS Direct Connect, é possível ter conectividade completa para vários ambientes, fornecendo uma rede estendida com performance consistente. A AWS oferece escalabilidade da largura de banda da conexão direta usando o grupo de agregação nativo (LAG) de 100 Gbps ou o BGP equal-cost multipath (ECMP). 

   1.  A AWS [Site-to-Site VPN](https://aws.amazon.com/vpn/) fornece um serviço de VPN gerenciada compatível com o protocolo de segurança da internet (IPsec). Quando uma conexão VPN é criada, cada conexão VPN inclui dois túneis para alta disponibilidade. 

1.  Siga a documentação da AWS para escolher uma opção de conectividade apropriada: 

   1.  Se você decidir usar o Direct Connect, selecione a largura de banda apropriada para sua conectividade. 

   1.  Se você usar uma AWS Site-to-Site VPN em vários locais para se conectar a uma Região da AWS, use uma [conexão de Site-to-Site VPN acelerada](https://docs.aws.amazon.com/vpn/latest/s2svpn/accelerated-vpn.html) para melhorar a performance da rede. 

   1.  Se o design da sua rede consistir em uma conexão VPN IPSec no [AWS Direct Connect](https://aws.amazon.com/directconnect/), considere o uso de VPN de IP privado para melhorar a segurança e conseguir segmentação. [A AWS Site-to-Site Private IP VPN](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-site-to-site-vpn-private-ip-vpns/) é implantada sobre a interface virtual de trânsito (VIF). 

   1.  [O AWS Direct Connect SiteLink](https://aws.amazon.com/blogs/aws/new-site-to-site-connectivity-with-aws-direct-connect-sitelink/) permite criar conexões redundantes e de baixa latência entre seus datacenters em todo o mundo, enviando dados pelo caminho mais rápido entre [os locais do AWS Direct Connect](https://aws.amazon.com/directconnect/locations/), contornando Regiões da AWS. 

1.  Valide sua configuração de conectividade antes de implantá-la na produção. Execute testes de segurança e performance para garantir que ela atenda aos requisitos de largura de banda, confiabilidade, latência e conformidade. 

1.  Monitore regularmente a performance e o uso da conectividade e otimize, se necessário. 

![\[Um fluxograma que descreve as opções a serem consideradas ao determinar se você precisa de desempenho determinístico nas suas redes ou não.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/deterministic-networking-flowchart.png)


 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [ Produtos de redes com a AWS](https://aws.amazon.com/products/networking/)
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [ Fazer a transição para o encaminhamento por latência no Amazon Route 53 ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html)
+ [ Endpoints da VPC ](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html)
+  [Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) 
+  [Building a Scalable and Secure Multi-VPC AWS Network Infrastructure (Criação de uma infraestrutura de rede da AWS de várias VPCs escaláveis e seguras)](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) 
+  [Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) 
+  [Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/what-is.html) 

 **Vídeos relacionados:** 
+ [ Connectivity to AWS and hybrid AWS network architectures (Conectividade com a AWS e arquiteturas de rede híbrida da AWS) ](https://www.youtube.com/watch?v=eqW6CPb58gs)
+ [ Optimizing Network Performance for Amazon EC2 Instances (Otimização da performance da rede para instâncias do Amazon EC2) ](https://www.youtube.com/watch?v=DWiwuYtIgu0)
+  [AWS Global Accelerator](https://www.youtube.com/watch?v=lAOhr-5Urfk) 
+  [Direct Connect](https://www.youtube.com/watch?v=DXFooR95BYc&t=6s) 
+  [AWS Transit Gateway Connect](https://www.youtube.com/watch?v=_MPY_LHSKtM&t=491s) 
+  [Soluções de VPN](https://www.youtube.com/watch?v=qmKkbuS9gRs) 
+  [Segurança com as soluções de VPN](https://www.youtube.com/watch?v=FrhVV9nG4UM) 

 **Exemplos relacionados:** 
+  [AWS Transit Gateway e soluções de segurança escaláveis](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions) 
+  [Workshops de redes da AWS](https://networking.workshop.aws/) 

# PERF04-BP04 Usar o balanceamento de carga para distribuir o tráfego em vários recursos
<a name="perf_networking_load_balancing_distribute_traffic"></a>

 Distribua o tráfego entre vários recursos e serviços para permitir que sua workload aproveite a elasticidade que a nuvem oferece. Também é possível usar o balanceamento de carga para descarregar a terminação de criptografia a fim de melhorar a performance, a confiabilidade e gerenciar e rotear o tráfego de maneira eficaz. 

 **Antipadrões comuns:** 
+  Você não considera os requisitos da workload ao escolher o tipo de balanceador de carga. 
+  Você não utiliza os recursos do balanceador de carga para otimização do desempenho. 
+  A workload é exposta diretamente à internet sem um balanceador de carga. 
+  Você roteia todo o tráfego da Internet por meio de balanceadores de carga existentes. 
+  Você usa o balanceamento de carga TCP genérico e faz com que cada nó de computação lide com a criptografia SSL. 

 **Benefícios de estabelecer esta prática recomendada:** Um balanceador de carga lida com a carga variável do tráfego da sua aplicação em uma única Zona de Disponibilidade ou em várias Zonas de Disponibilidade e permite alta disponibilidade, ajuste de escala automático e melhor utilização de sua workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Os balanceadores de carga atuam como o ponto de entrada para sua workload, a partir do qual distribuem o tráfego para seus destinos de back-end, como instâncias de computação ou contêineres, para melhorar a utilização. 

 Escolher o tipo certo de balanceador de carga é a primeira etapa para otimizar sua arquitetura. Comece listando as características da workload, como protocolo (como TCP, HTTP, TLS ou WebSockets), o tipo de destino (como instâncias, contêineres ou tecnologia sem servidor), requisitos da aplicação (como conexões de execução longa, autenticação de usuários ou adesão) e posicionamento (como região, zona local, Outpost ou isolamento por zona). 

 A AWS fornece vários modelos para que suas aplicações usem o balanceamento de carga. [O Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) é o mais adequado para balanceamento de carga de tráfego HTTP e HTTPS, e oferece roteamento avançado de solicitação direcionado para a entrega de arquiteturas de aplicações modernas, inclusive microsserviços e contêineres. 

 [O Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) é o mais adequado para o balanceamento de carga de tráfego TCP que exija performance extrema. Ele é capaz de processar milhões de solicitações por segundo enquanto mantém latências ultrabaixas, e também é otimizado para lidar com padrões de tráfego súbitos e voláteis. 

 [O Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) oferece gerenciamento integrado de certificados e descriptografia SSL/TLS, o que proporciona a flexibilidade de gerenciar centralmente as configurações SSL do balanceador de carga e descarregar de sua workload as interações com uso intenso de CPU. 

 Depois de escolher o balanceador de carga certo, você pode começar a utilizar seus recursos para reduzir a quantidade de esforço que seu back-end precisa fazer para atender o tráfego. 

 Por exemplo, ao usar tanto o Application Load Balancer (ALB) como o Network Load Balancer (NLB), é possível realizar o descarregamento de criptografia SSL/TLS, que é uma oportunidade de evitar que o handshake TLS com uso intenso da CPU seja concluído pelos destinos e também melhorar o gerenciamento de certificados. 

 Ao configurar o descarregamento de SSL/TLS no balanceador de carga, ele se torna responsável pela criptografia do tráfego de e para os clientes enquanto entrega o tráfego não criptografado aos back-ends, liberando os recursos de back-end e melhorando o tempo de resposta para os clientes. 

 O Application Load Balancer também pode fornecer tráfego HTTP/2 sem precisar comportá-lo em seus destinos. Essa simples decisão pode melhorar o tempo de resposta da aplicação, já que o HTTP/2 usa conexões TCP de forma mais eficiente. 

 Os requisitos de latência da workload devem ser considerados ao definir a arquitetura. Como exemplo, se você tiver uma aplicação sensível à latência, poderá decidir usar o Network Load Balancer, que oferece latências extremamente baixas. Como alternativa, você pode decidir aproximar a workload dos clientes utilizando o Application Load Balancer em [zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) ou mesmo o [AWS Outposts](https://aws.amazon.com/outposts/rack/). 

 Outra consideração para workloads sensíveis à latência é o balanceamento de carga entre zonas. Com o balanceamento de carga entre zonas, cada nó do balanceador de carga distribui o tráfego entre os destinos registrados em todas as Zonas de Disponibilidade habilitadas. 

 Use o Auto Scaling integrado ao balanceador de carga. Um dos principais aspectos de um sistema com desempenho eficiente está relacionado ao dimensionamento correto dos recursos de back-end. Para fazer isso, é possível utilizar as integrações do balanceador de carga para os recursos de destino de back-end. Ao usar a integração do balanceador de carga com os grupos do Auto Scaling, os destinos serão adicionados ou removidos do balanceador de carga conforme exigido em resposta ao tráfego recebido. Os balanceadores de carga também podem se integrar com o [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html) e o [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) para workloads em contêineres. 
+  [Amazon ECS: balanceamento de carga do serviço](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html) 
+  [Balanceamento de carga da aplicação no Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) 
+  [Balanceamento de carga da rede no Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/network-load-balancing.html) 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Defina seus requisitos de balanceamento de carga, incluindo excelente volume, disponibilidade e escalabilidade de aplicações. 
+  Escolha o tipo certo de balanceador de carga para sua aplicação. 
  +  Use o Application Load Balancer para workloads HTTP/HTTPS. 
  +  Use o Network Load Balancer para workloads que não são HTTP que executam TCP ou UDP. 
  +  Use uma combinação de ambos ([ALB como alvo do NLB](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/)) se você quiser aproveitar os recursos de ambos os produtos. Por exemplo, é possível fazer isso se você quiser usar os IPs estáticos do NLB junto com o roteamento baseado em cabeçalho HTTP do ALB, ou se quiser expor a workload HTTP em um [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-share-your-services.html). 
  +  Para uma comparação completa dos balanceadores de carga, consulte [Comparação de produtos do ELB](https://aws.amazon.com/elasticloadbalancing/features/). 
+  Use o descarregamento de SSL/TLS, se possível. 
  +  Configure receptores HTTPS/TLS com o [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) e o [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-tls-listener.html) integrados com o [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/). 
  +  Observe que algumas workloads podem exigir criptografia completa por motivos de conformidade. Nesse caso, é um requisito para permitir a criptografia nos destinos. 
  +  Para práticas recomendadas de segurança, consulte [SEC09-BP02 Aplicar a criptografia em trânsito](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_data_transit_encrypt.html). 
+  Escolha o algoritmo de roteamento certo (apenas ALB). 
  +  O algoritmo de roteamento pode fazer a diferença em como os destinos de back-end são bem-utilizados e, portanto, na forma como afetam o desempenho. Por exemplo, a ALB fornece [duas opções para algoritmos de roteamento](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm): 
  +  **Solicitações menos urgentes:** use para obter uma melhor distribuição de carga para seus destinos de back-end em casos nos quais as solicitações para a aplicação variam em complexidade ou os destinos variam na capacidade de processamento. 
  +  **Round robin:** use quando as solicitações e os destinos forem semelhantes, ou se você precisar distribuir as solicitações igualmente entre os destinos. 
+  Considere isolamento por zona ou entre zonas. 
  +  Desative a opção entre zonas (isolamento por zona) para melhorias de latência e domínios com falha de zona. Ele está desativado por padrão no NLB e no [ALB. Você pode desativá-lo por grupo-alvo](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html). 
  +  Ative a opção entre zonas para maior disponibilidade e flexibilidade. Por padrão, a opção entre zonas está ativada para o ALB. No [NLB, você pode ativá-la por grupo-alvo.](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-cross-zone.html). 
+  Ative as manutenções de funcionamento de HTTP para as workloads HTTP (apenas ALB). Com esse recurso, o balanceador de carga pode reutilizar as conexões de back-end até expirar o tempo limite da manutenção de funcionamento, melhorando a solicitação HTTP e o tempo de resposta, além de reduzir a utilização de recursos nos destinos de back-end. Para obter detalhes sobre como fazer isso para Apache e Nginx, consulte [Quais são as configurações ideais para usar o Apache ou o NGINX como servidor de back-end para o ELB?](https://aws.amazon.com/premiumsupport/knowledge-center/apache-backend-elb/) 
+  Ative o monitoramento do balanceador de carga. 
  +  Ative os logs de acesso para o [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-access-logging.html) e o [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html). 
  +  Os principais campos a considerar para o ALB são `request_processing_time`, o `request_processing_time`e o `response_processing_time`. 
  +  Os principais campos a considerar para o NLB são `connection_time` e o `tls_handshake_time`. 
  +  Esteja pronto para consultar os logs quando precisar deles. Você pode usar o Amazon Athena para consultar tanto [os logs do ALB](https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html) e [os logs do NLB](https://docs.aws.amazon.com/athena/latest/ug/networkloadbalancer-classic-logs.html). 
  +  Crie alarmes para métricas relacionadas ao desempenho, como [`TargetResponseTime` para o ALB](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Comparação de produtos do ELB ](https://aws.amazon.com/elasticloadbalancing/features/) 
+  [AWS Global Infrastructure (Infraestrutura global da AWS) ](https://aws.amazon.com/about-aws/global-infrastructure/) 
+  [Improving Performance and Reducing Cost Using Availability Zone Affinity (Melhorar o desempenho e reduzir os custos usando a afinidade de zona de disponibilidade) ](https://aws.amazon.com/blogs/architecture/improving-performance-and-reducing-cost-using-availability-zone-affinity/) 
+  [Step by step for Log Analysis with Amazon Athena (Passo a passo para a análise de logs com o Amazon Athena) ](https://github.com/aws/elastic-load-balancing-tools/tree/master/amazon-athena-for-elb) 
+  [Querying Application Load Balancer logs (Consulta de logs do Application Load Balancer)](https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html) 
+  [Monitor your Application Load Balancers (Monitore o Application Load Balancers)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html) 
+  [Monitor your Network Load Balancer (Monitore o Network Load Balancer)](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-monitoring.html) 
+  [Use Elastic Load Balancing to distribute traffic across the instances in your Auto Scaling group (Usar o Elastic Load Balancing para distribuir tráfego entre as instâncias no grupo do Auto Scaling)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2018: Elastic Load Balancing: Deep Dive and Best Practices (AWS re:Invent 2018: Elastic Load Balancing: aprofundamento e práticas recomendadas)](https://www.youtube.com/watch?v=VIgAT7vjol8) 
+  [AWS re:Invent 2021 - How to choose the right load balancer for your AWS workloads (AWS re:Invent 2021: como escolher o balanceador de carga certo para suas workloads da AWS) ](https://www.youtube.com/watch?v=p0YZBF03r5A) 
+  [AWS re:Inforce 2022 - How to use Elastic Load Balancing to enhance your security posture at scale (AWS re:Inforce 2022: como usar o Elastic Load Balancing para melhorar seu procedimento de segurança em escala)](https://www.youtube.com/watch?v=YhNc5VSzOGQ) 
+  [AWS re:Invent 2019: Get the most from Elastic Load Balancing for different workloads (AWS re:Invent 2019: aproveite ao máximo o Elastic Load Balancing para diferentes workloads)](https://www.youtube.com/watch?v=HKh54BkaOK0) 

 **Exemplos relacionados:** 
+  [CDK and CloudFormation samples for Log Analysis with Amazon Athena (Exemplos de CDK e CloudFormation para análise de log com o Amazon Athena) ](https://github.com/aws/elastic-load-balancing-tools/tree/master/log-analysis-elb-cdk-cf-template) 

# PERF04-BP05 Escolher os protocolos de rede para melhorar o desempenho
<a name="perf_networking_choose_network_protocols_improve_performance"></a>

 Tome decisões sobre protocolos de comunicação entre sistemas e redes com base no impacto na performance da workload. 

 Há uma relação entre latência e largura de banda para alcançar o throughput. Por exemplo, se a transferência de arquivos estiver usando TCP (Protocolo de Controle de Transmissão), latências mais altas provavelmente reduzirão o throughput geral. Existem abordagens para corrigir isso com ajuste de TCP e protocolos de transferência otimizados, mas uma solução é usar o User Datagram Protocol (UDP, protocolo de datagrama de usuário). 

 **Antipadrões comuns:** 
+  Você usa TCP para todas as workloads, independentemente dos requisitos de performance. 

 **Benefícios de estabelecer esta prática recomendada:** verificar se um protocolo apropriado é usado para comunicação entre usuários e componentes da workload ajuda a melhorar a experiência geral do usuário para as aplicações. Por exemplo, o UDP sem conexão permite alta velocidade, mas não oferece retransmissão ou alta confiabilidade. TCP é um protocolo completo, mas requer maior sobrecarga para processar os pacotes. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Se você puder escolher protocolos diferentes para sua aplicação e tiver experiência nessa área, otimize sua aplicação e a experiência do usuário final usando um protocolo diferente. Observe que essa abordagem apresenta dificuldades significativas e só deve ser experimentada se você tiver otimizado sua aplicação de outras maneiras primeiro. 

 Uma consideração primária para melhorar o desempenho da workload é entender os requisitos de latência e throughput e escolher os protocolos de rede que otimizam o desempenho. 

 **Quando considerar o uso do TCP** 

 O TCP oferece entrega de dados confiável e pode ser usado para comunicação entre componentes da workload em que a confiabilidade e a entrega garantida de dados é importante. Muitas aplicações baseadas na web dependem de protocolos baseados em TCP, como HTTP e HTTPS, para abrir soquetes TCP para comunicação entre componentes da aplicação. A transferência de dados por e-mail e arquivo são aplicações comuns que também usam o TCP, pois é um mecanismo de transferência simples e confiável entre os componentes da aplicação. Usar o TLS com TCP pode adicionar sobrecarga à comunicação, o que pode resultar em maior latência e redução de throughput, mas traz a vantagem da segurança. A sobrecarga vem principalmente da sobrecarga adicionada do processo de handshake, que pode levar várias idas e voltas para ser concluído. Quando o handshake for concluído, a sobrecarga da criptografia e descriptografia de dados será relativamente pequena. 

 **Quando considerar o uso do UDP** 

 O UDP é um protocolo sem conexão e, portanto, é adequado para aplicações que precisam de uma transmissão rápida e eficiente, como log, monitoramento e dados de VoIP. Além disso, considere usar o UDP se você tiver componentes da workload que respondam a pequenas consultas de grandes números de clientes para garantir um desempenho ideal da workload. O Datagram Transport Layer Security (DTLS) é o equivalente UDP do Transport Layer Security (TLS). Ao usar DTLS com UDP, a sobrecarga vem da criptografia e descriptografia de dados, já que o processo de handshake é simplificado. O DTLS também adiciona uma pequena quantidade de sobrecarga aos pacotes de UDP, já que inclui campos adicionais para indicar os parâmetros de segurança e detectar violações. 

 **Quando considerar o uso do SRD** 

 O SRD (datagrama confiável escalável) é um protocolo de transporte de rede otimizado para workloads de alto throughput devido à sua capacidade de fazer o balanceamento de carga do tráfego em vários caminhos e de se recuperar rapidamente de quedas de pacote ou falhas no link. Assim, o SRD é melhor nos casos de workloads de computação de alta performance (HPC) que exigem comunicação de alto throughput e baixa latência entre os nós de computação. Isso pode incluir tarefas de processamento paralelas, como simulação, modelagem e análise de dados que envolvem uma grande quantidade de transferência de dados entre os nós. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Use o [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) e o [AWS Transfer Family](https://aws.amazon.com/aws-transfer-family/) para melhorar o throughput de suas aplicações de transferência de arquivos online. O serviço AWS Global Accelerator ajuda você a obter baixa latência entre os dispositivos cliente e a workload na AWS. Com o AWS Transfer Family, é possível usar protocolos baseados em TCP, como SFTP (Protocolo de transferência de arquivos de Secure Shell) e FTPS (Protocolo de transferência de arquivos por SSL), para escalar e gerenciar com segurança as transferências de arquivos para os serviços de armazenamento da AWS. 

1.  Use a latência de rede para determinar se o TCP é adequado para comunicação entre os componentes da workload. Se a latência de rede entre a aplicação cliente e o servidor for alta, o handshake de três vias do TCP pode levar um tempo, afetando, assim, a capacidade de resposta da aplicação. Métricas como tempo até o primeiro byte (TTFB) e tempo de ida e volta (RTT) podem ser usadas para medir a latência da rede. Se sua workload fornece conteúdo dinâmico aos usuários, considere usar o [Amazon CloudFront](https://aws.amazon.com/cloudfront/), que estabelece uma conexão persistente com cada origem de conteúdo dinâmico para remover o tempo de configuração da conexão que, de outra forma, diminuiria a velocidade de cada solicitação do cliente. 

1.  Usar TLS com TCP ou UDP pode resultar em maior latência e menor throughput para a workload devido ao impacto da criptografia e descriptografia. Para essas workloads, considere o descarregamento de SSL/TLS no [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) para melhorar o desempenho da workload, permitindo que o balanceador de carga lide com o processo de criptografia e descriptografia de SSL/TLS em vez de deixar que as instâncias de back-end façam isso. Isso pode ajudar a reduzir a utilização da CPU nas instâncias de back-end, o que pode melhorar o desempenho e aumentar a capacidade. 

1.  Use o [Network Load Balancer (NLB)](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/) para implantar serviços que dependem do protocolo UDP, como autenticação e autorização, registro em log, DNS, IoT e mídia de streaming, visando melhorar o desempenho e a confiabilidade da workload. O NLB distribui o tráfego de UDP de entrada em vários destinos, permitindo escalar a workload horizontalmente, aumentar a capacidade e reduzir a sobrecarga de um único destino. 

1.  Para suas workloads de computação de alta performance (HPC), considere usar a funcionalidade do [Adaptador de Rede Elástica (ENA) Express,](https://aws.amazon.com/about-aws/whats-new/2022/11/elastic-network-adapter-ena-express-amazon-ec2-instances/) que usa o protocolo SRD para melhorar o desempenho da rede fornecendo uma maior largura de banda de fluxo único (25 Gbps) e menor latência final (99,9 percentil) para o tráfego de rede entre instâncias do EC2. 

1.  Use o [Application Load Balancer(ALB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) para rotear e balancear a carga do tráfego de gRPC (Chamadas de procedimento remoto) entre os componentes da workload ou entre os serviços e clientes com gRPC habilitadas. As gRPC usam o protocolo HTTP/2 baseado em TCP para transporte e oferece benefícios de desempenho, como pegada de rede mais leve, compactação, serialização binária eficiente, suporte para várias linguagens e streaming bidirecional. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Instâncias otimizadas para Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html) 
+  [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
+  [Rede avançada do EC2 no Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html) 
+  [Rede avançada do EC2 no Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking.html) 
+  [Grupos de posicionamento do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) 
+  [Como habilitar a rede avançada com o Adaptador de Rede Elástica (ENA) em instâncias Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) 
+  [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
+  [Produtos de redes com a AWS](https://aws.amazon.com/products/networking/) 
+  [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw) 
+  [Fazer a transição para o roteamento baseado em latência no Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html) 
+  [VPC Endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) 
+  [Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 

 **Vídeos relacionados:** 
+  [Connectivity to AWS and hybrid AWS network architectures (Conectividade com a AWS e arquiteturas de rede híbrida da AWS)](https://www.youtube.com/watch?v=eqW6CPb58gs) 
+  [Optimizing Network Performance for Amazon EC2 Instances (Otimização da performance da rede para instâncias do Amazon EC2)](https://www.youtube.com/watch?v=DWiwuYtIgu0) 

 **Exemplos relacionados:** 
+  [AWS Transit Gateway e soluções de segurança escaláveis](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions) 
+  [Workshops de redes da AWS](https://networking.workshop.aws/) 

# PERF04-BP06 Escolher o local da workload com base nos requisitos de rede
<a name="perf_networking_choose_workload_location_network_requirements"></a>

Avalie as opções para o posicionamento de recursos visando reduzir a latência da rede e melhorar o throughput, proporcionando uma ótima experiência do usuário ao reduzir os tempos de carregamento da página e de transferência de dados.

 **Antipadrões comuns:** 
+  Você consolida todos os recursos da workload em uma única localização geográfica. 
+  Você escolhe a Região mais próxima ao seu local, mas não ao usuário final da workload. 

 **Benefícios de estabelecer esta prática recomendada:** A experiência do usuário é muito afetada pela latência entre o usuário e sua aplicação. Ao usar Regiões da AWS adequadas e a rede global privada da AWS, você pode reduzir a latência e oferecer uma melhor experiência aos usuários remotos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Recursos, como instâncias do Amazon EC2, são colocados em zonas de disponibilidade em [Regiões da AWS](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/), [zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/), [AWS Outposts](https://aws.amazon.com/outposts/)ou [AWS Wavelength](https://aws.amazon.com/wavelength/) . A escolha desse local influencia o throughput e a latência da rede de determinado local do usuário. Serviços de borda, como [Amazon CloudFront](https://aws.amazon.com/cloudfront/) e o [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) também podem ser usados para melhorar o desempenho da rede, seja armazenando o conteúdo em cache nos locais da borda ou oferecendo aos usuários um ótimo caminho para a workload por meio da rede global da AWS. 

 O Amazon EC2 oferece grupos de posicionamento para redes. Um grupo de posicionamento é um agrupamento lógico de instâncias para diminuir a latência. O uso de grupos de posicionamento com tipos de instância compatíveis e um Adaptador de Rede Elástica (ENA) permite que as workloads participem de uma rede de baixa latência, com oscilação reduzida e de 25 Gbps. Recomenda-se o uso de grupos de posicionamento para workloads que se beneficiam de baixa latência de rede, alto throughput de rede ou ambos. 

 Serviços sensíveis à latência são fornecidos em locais de borda usando uma rede global da AWS, como o [Amazon CloudFront](https://aws.amazon.com/cloudfront/). Esses locais de borda costumam oferecer serviços, como rede de entrega de conteúdo (CDN) e sistema de nomes de domínio (DNS). Ao ter esses serviços na borda, as workloads podem responder com baixa latência a solicitações de conteúdo ou resolução de DNS. Esses serviços também fornecem serviços geográficos, como direcionamento geográfico de conteúdo (fornecendo conteúdo diferente conforme o local do usuário final) ou encaminhamento por latência para direcionar os usuários finais à região mais próxima (latência mínima). 

 Use serviços de borda para reduzir a latência e possibilitar o armazenamento do conteúdo em cache. Configure corretamente o controle de cache para DNS e HTTP/HTTPS a fim de aproveitar ao máximo essas abordagens. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Capture informações sobre o tráfego IP que entra e sai das interfaces de rede. 
  + [ Registro em log do tráfego IP usando logs de fluxo de VPC ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
  + [ Como o endereço IP do cliente é preservado no AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/preserve-client-ip-address.headers.html)
+  Analise os padrões de acesso à rede em sua workload para identificar como os usuários utilizam sua aplicação. 
  +  Use ferramentas de monitoramento, como [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) e o [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), para coletar dados sobre as atividades da rede. 
  +  Analise os dados para identificar o padrão de acesso à rede. 
+  Selecione as Regiões para implantação da workload com base nos seguintes elementos fundamentais: 
  +  **A localização dos seus dados:** para aplicações com uso intenso de dados (como big data e machine learning), o código da aplicação deve ser executado o mais perto possível dos dados. 
  +  **A localização dos seus usuários**: para aplicações voltadas ao usuário, escolha uma Região (ou Regiões) próxima dos clientes de sua workload. 
  +  **Outras restrições**: leve em conta restrições, como custo e conformidade, conforme explicado em [O que considerar ao selecionar uma região para suas workloads.](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
+  Use [zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) para executar workloads como renderização de vídeo. As zonas locais permitem que você se beneficie de ter recursos de computação e armazenamento mais próximos dos usuários finais. 
+  Use [AWS Outposts](https://aws.amazon.com/outposts/) para workloads que precisam permanecer on-premises e onde você deseja que essa workload seja executada ininterruptamente com o restante de suas workloads na AWS. 
+  Aplicações, como streaming de vídeo ao vivo em alta resolução, áudio de alta fidelidade ou realidade aumentada/realidade virtual (RA/RV), exigem latência ultrabaixa para dispositivos 5G. Para tais aplicações, considere o [AWS Wavelength](https://aws.amazon.com/wavelength/)O AWS Wavelength incorpora serviços de armazenamento e computação da AWS em redes 5G, fornecendo a infraestrutura móvel de computação de borda para desenvolver, implantar e escalar aplicações de latência ultrabaixa. 
+  Use armazenamento em cache local ou [soluções de armazenamento em cache da AWS](https://aws.amazon.com/caching/aws-caching/) para ativos usados com frequência a fim de aumentar a performance, reduzir a movimentação de dados e reduzir o impacto ambiental.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_networking_choose_workload_location_network_requirements.html)
+  Use serviços que podem ajudar você a executar código mais perto dos usuários da workload, como a seguir:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_networking_choose_workload_location_network_requirements.html)
+  Algumas aplicações exigem pontos de entrada fixos ou maior desempenho ao reduzir a tremulação e a latência de primeiro byte, além de aumentar o throughput. Essas aplicações podem se beneficiar de serviços de rede que fornecem endereços IP anycast estáticos e terminação TCP em locais da borda. [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) pode melhorar o desempenho de suas aplicações em até 60% e fornecer failover rápido para arquiteturas multirregionais. O AWS Global Accelerator fornece endereços IP anycast estáticos que servem como um ponto de entrada fixo para suas aplicações hospedadas em uma ou mais Regiões da AWS. Esses endereços IP permitem que o tráfego entre na rede global da AWS o mais próximo possível dos usuários. O AWS Global Accelerator reduz o tempo de configuração da conexão inicial ao estabelecer uma conexão TCP entre o cliente e o local da borda da AWS mais próximo ao cliente. Analise o uso do AWS Global Accelerator para melhorar o desempenho das workloads de TCP/UDP e forneça failover rápido para arquiteturas de várias Regiões. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [ COST07-BP02 Implementar regiões com base nos custos ](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_pricing_model_region_cost.html)
+ [ COST08-BP03 Implementar serviços para reduzir custos de transferência de dados ](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_data_transfer_implement_services.html)
+ [ REL10-BP01 Implantar a workload em vários locais ](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_fault_isolation_multiaz_region_system.html)
+ [ REL10-BP02 Escolher os locais apropriados para sua implantação de vários locais ](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_fault_isolation_select_location.html)
+ [ SUS01-BP01 Escolher a região com base nos requisitos empresariais e nas metas de sustentabilidade ](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_region_a2.html)
+ [ SUS02-BP04 Otimizar o posicionamento geográfico das workloads com base nos respectivos requisitos de rede ](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_user_a5.html)
+ [ SUS04-BP07 Minimizar a movimentação de dados entre redes ](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_data_a8.html)

 **Documentos relacionados:** 
+ [AWS Global Infrastructure (Infraestrutura global da AWS) ](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [AWS Local Zones and AWS Outposts, choosing the right technology for your edge workload (Zonas locais da AWS e AWS Outposts: como escolher a tecnologia certa para sua workload de borda) ](https://aws.amazon.com/blogs/compute/aws-local-zones-and-aws-outposts-choosing-the-right-technology-for-your-edge-workload/)
+ [ Grupos de posicionamento ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
+ [ zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)
+ [AWS Outposts](https://aws.amazon.com/outposts/)
+ [AWS Wavelength](https://aws.amazon.com/wavelength/)
+ [ Amazon CloudFront ](https://aws.amazon.com/cloudfront/)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [AWS Direct Connect](https://aws.amazon.com/directconnect/)
+ [AWS Site-to-Site VPN](https://aws.amazon.com/vpn/site-to-site-vpn/)
+ [ Amazon Route 53 ](https://aws.amazon.com/route53/)

 **Vídeos relacionados:** 
+ [AWS Local Zones Explainer Video (Vídeo de explicação de zonas locais da AWS) ](https://www.youtube.com/watch?v=JHt-D4_zh7w)
+ [AWS Outposts: Overview and How it Works (AWS Outposts: visão geral e como funciona ](https://www.youtube.com/watch?v=ppG2FFB0mMQ)
+ [AWS re:Invent 2021 - AWS Outposts: Bringing the AWS experience on premises (AWS re:Invent 2021 - AWS Outposts: como trazer a experiência da AWS para ambientes on-premises) ](https://www.youtube.com/watch?v=FxVF6A22498)
+ [AWS re:Invent 2020: AWS Wavelength: Run apps with ultra-low latency at 5G edge (AWS re:Invent 2020: AWS Wavelength: execute aplicativos com latência ultrabaixa na borda 5G) ](https://www.youtube.com/watch?v=AQ-GbAFDvpM)
+ [AWS re:Invent 2022 - AWS Local Zones: Building applications for a distributed edge (AWS re:Invent 2022: zonas locais da AWS: como criar aplicações para uma borda distribuída) ](https://www.youtube.com/watch?v=bDnh_d-slhw)
+ [AWS re:Invent 2021 - Building low-latency websites with Amazon CloudFront (AWS re:Invent 2021: criação de sites de baixa latência com o Amazon CloudFront) ](https://www.youtube.com/watch?v=9npcOZ1PP_c)
+ [AWS re:Invent 2022 - Improve performance and availability with AWS Global Accelerator (AWS re:Invent 2022: melhore a performance e a disponibilidade com o AWS Global Accelerator) ](https://www.youtube.com/watch?v=s5sjsdDC0Lg)
+ [AWS re:Invent 2022 - Build your global wide area network using AWS (AWS re:Invent 2022: crie sua rede de longa distância usando a AWS) ](https://www.youtube.com/watch?v=flBieylTwvI)
+ [AWS re:Invent 2020: Global traffic management with Amazon Route 53 (AWS re:Invent 2020: gerenciamento de tráfego global com o Amazon Route 53) ](https://www.youtube.com/watch?v=E33dA6n9O7I)

 **Exemplos relacionados:** 
+ [ Workshop do AWS Global Accelerator](https://catalog.us-east-1.prod.workshops.aws/workshops/effb1517-b193-4c59-8da5-ce2abdb0b656/en-US)
+ [ Handling Rewrites and Redirects using Edge Functions (Lidar com reescritas e redirecionamentos usando funções da borda) ](https://catalog.us-east-1.prod.workshops.aws/workshops/814dcdac-c2ad-4386-98d5-27d37bb77766/en-US)

# PERF04-BP07 Otimizar a configuração da rede com base em métricas
<a name="perf_networking_optimize_network_configuration_based_on_metrics"></a>

 Use dados coletados e analisados para tomar decisões bem informadas sobre a otimização da configuração da rede. 

 **Antipadrões comuns:** 
+  Você pressupõe que todos os problemas relacionados à performance são relacionados à aplicação. 
+  Você só testa a performance da rede a partir de um local próximo ao local em que implantou a carga de trabalho. 
+  Você usa configurações-padrão para todos os serviços de rede. 
+  Você provisiona em excesso recursos de rede para fornecer capacidade suficiente. 

 **Benefícios de estabelecer esta prática recomendada:** coletar as métricas necessárias da rede da AWS e implementar ferramentas de monitoramento de rede permite entender o desempenho da rede e otimizar as configurações dela. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Monitorar o tráfego de entrada e saída das VPCs, sub-redes ou interfaces de rede é fundamental para entender como utilizar os recursos de rede da AWS e otimizar as configurações da rede. Ao usar as ferramentas de rede da AWS a seguir, é possível verificar mais informações sobre o uso do tráfego, o acesso à rede e os logs. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Identifique as principais métricas de desempenho, como latência ou perda de pacotes. A AWS fornece diversas ferramentas que podem ajudar você a coletar essas métricas. Ao usar as ferramentas a seguir, é possível verificar mais informações sobre o uso do tráfego, o acesso à rede e os logs:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_networking_optimize_network_configuration_based_on_metrics.html)
+  Identifique os principais interlocutores e os padrões de tráfego de aplicações usando VPC e logs de fluxo do AWS Transit Gateway. 
+  Avalie e otimize sua arquitetura de rede atual, incluindo VPCs, sub-redes e roteamento. Como exemplo, você pode avaliar como diferentes emparelhamentos de VPC ou AWS Transit Gateway podem ajudar a melhorar a rede em sua arquitetura. 
+  Avalie os caminhos de roteamento em sua rede para verificar se o caminho mais curto entre os destinos é sempre usado. O Network Access Analyzer pode ajudar nessa tarefa. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 
+  [Registro em log de consulta ao DNS público](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html) 
+  [O que é o IPAM?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) 
+  [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 
+  [O que é o Network Access Analyzer?](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html) 
+  [Métricas do CloudWatch para suas VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cloudwatch.html) 
+  [Otimize o desempenho e reduza os custos de análise da rede com os logs de fluxo da VPC no formato Apache Parquet ](https://aws.amazon.com/blogs/big-data/optimize-performance-and-reduce-costs-for-network-analytics-with-vpc-flow-logs-in-apache-parquet-format/) 
+  [Monitoramento de suas redes globais e principais com métricas do Amazon CloudWatch](https://docs.aws.amazon.com/vpc/latest/tgwnm/monitoring-cloudwatch-metrics.html) 
+  [Monitore continuamente o tráfego e os recursos da rede](https://docs.aws.amazon.com/whitepapers/latest/security-best-practices-for-manufacturing-ot/continuously-monitor-network-traffic-and-resources.html) 

 **Vídeos relacionados:** 
+  [Networking best practices and tips with the AWS Well-Architected Framework (Práticas recomendadas e dicas de redes com o AWS Well-Architected Framework) ](https://www.youtube.com/watch?v=wOMNpG49BeM) 
+  [Monitoring and troubleshooting network traffic (Monitoramento e resolução de problemas de tráfego de rede) ](https://www.youtube.com/watch?v=Ed09ReWRQXc) 

 **Exemplos relacionados:** 
+  [Workshops de redes da AWS](https://networking.workshop.aws/) 
+  [Monitoramento de rede da AWS](https://github.com/aws-samples/monitor-vpc-network-patterns) 

# Processo e cultura
<a name="a-process-culture"></a>

# PERFORMANCE 5. Como suas práticas e cultura organizacionais contribuem para a eficiência do desempenho em sua workload?
<a name="perf-05"></a>

 Ao arquitetar workloads, há princípios e práticas que você pode adotar para ajudar na melhor execução de workloads de nuvem eficientes e de alto desempenho. Para adotar uma cultura que promova a eficiência do desempenho das workloads na nuvem, considere estes princípios e práticas fundamentais: 

**Topics**
+ [PERF05-BP01 Estabeleça indicadores-chave de desempenho (KPIs) para medir a integridade e o desempenho da workload](perf_process_culture_establish_key_performance_indicators.md)
+ [PERF05-BP02 Use soluções de monitoramento para entender as áreas em que o desempenho é mais crítico](perf_process_culture_use_monitoring_solutions.md)
+ [PERF05-BP03 Defina um processo para melhorar a performance da workload](perf_process_culture_workload_performance.md)
+ [PERF05-BP04 Faça o teste de carga da workload](perf_process_culture_load_test.md)
+ [PERF05-BP05 Use a automação para corrigir proativamente problemas relacionados ao desempenho](perf_process_culture_automation_remediate_issues.md)
+ [PERF05-BP06 Mantenha a workload e os serviços atualizados](perf_process_culture_keep_workload_and_services_up_to_date.md)
+ [PERF05-BP07 Analise as métricas regularmente](perf_process_culture_review_metrics.md)

# PERF05-BP01 Estabeleça indicadores-chave de desempenho (KPIs) para medir a integridade e o desempenho da workload
<a name="perf_process_culture_establish_key_performance_indicators"></a>

 Identifique os KPIs que medem o desempenho da workload de forma quantitativa e qualitativa. Os KPIs ajudam você a medir a integridade e o desempenho de uma workload relacionada a uma meta empresarial. 

 **Antipadrões comuns:** 
+  Você só monitora as métricas no nível do sistema para obter informações da workload e não compreende aos impactos dessas métricas nos negócios. 
+  Você pressupõe que os KPIs já estejam publicados e compartilhados como dados de métricas comuns. 
+  Você não define um KPI quantitativo e mensurável. 
+  Você não alinha os KPIs às metas ou estratégias empresariais. 

 **Benefícios de estabelecer esta prática recomendada:** Identificar KPIs específicos que representam a integridade e o desempenho da workload ajuda a alinhar as equipes em suas prioridades e a definir resultados empresariais bem-sucedidos. O compartilhamento dessas métricas com todos os departamentos fornece visibilidade e alinhamento dos limites, das expectativas e do impacto nos negócios. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Os KPIs permitem que as empresas e as equipes de engenharia alinhem a medição das metas e estratégias de como esses fatores são combinados para produzir resultados empresariais. Por exemplo, a workload de um site pode usar o tempo de carregamento da página como uma indicação de desempenho geral. Essa métrica seria um dos vários pontos de dados que medem a experiência do usuário. Além de identificar os limites do tempo de carregamento da página, documente o resultado esperado ou o risco da empresa se o desempenho ideal não for atingido. Um longo tempo de carregamento da página afeta diretamente os usuários finais, diminui a classificação da experiência do usuário e pode resultar em perda de clientes. Ao definir os limites dos KPIs, combine os testes comparativos do setor e as expectativas dos usuários finais. Por exemplo, se o teste comparativo do setor atual for o carregamento de uma página da web em dois segundos, mas os usuários finais esperarem que uma página da web seja carregada em um segundo, você deverá pensar nos dois pontos de dados ao estabelecer o KPI. 

 Sua equipe deve avaliar os KPIs da workload usando dados detalhados em tempo real e dados históricos para referência, e criar painéis que calculem as métricas nos dados de KPI para derivar informações operacionais e de utilização. Os KPIs devem ser documentados e incluir limites que apoiem as metas e estratégias empresariais, bem como mapeados de acordo com as métricas que estão sendo monitoradas. Os KPIs devem ser revisitados quando mudam as metas e as estratégias da empresa ou os requisitos dos usuários finais.   

## Etapas da implementação
<a name="implementation-steps"></a>

1.  Identifique e documente as principais partes interessadas da empresa. 

1.  Trabalhe com essas partes interessadas para definir e documentar os objetivos da workload. 

1.  Analise as práticas recomendadas do setor para identificar KPIs relevantes alinhados aos objetivos da workload. 

1.  Use as práticas recomendadas do setor e os objetivos da workload para definir metas de KPI da workload. Use essas informações para definir limites de KPI no nível de gravidade ou de alarme. 

1.  Identifique e documente o risco e o impacto no caso de um KPI não ser atendido. 

1.  Identifique e documente métricas que podem ajudar a estabelecer os KPIs. 

1.  Use ferramentas de monitoramento, como [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) ou [AWS Config](https://aws.amazon.com/config/) para coletar métricas e medir KPIs. 

1.  Use painéis para visualizar e comunicar os KPIs com as partes interessadas. 

1.  Revise e analise regularmente as métricas para identificar áreas da workload que precisam ser aprimoradas. 

1.  Revise os KPIs quando as metas empresariais ou a performance da workload mudarem. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Documentação da CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [AWS Partners de monitoramento, registro em log e performance](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+  [Documentação do X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+  [Using Amazon CloudWatch dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html?ref=wellarchitected) 
+  [Quick KPIs](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2019: Scaling up to your first 10 million users](https://www.youtube.com/watch?v=kKjm4ehYiMs&ref=wellarchitected) 
+  [Cut through the chaos: Gain operational visibility and insight](https://www.youtube.com/watch?v=nLYGbotqHd0&ref=wellarchitected) 
+  [Build a monitoring plan](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) 

 **Exemplos relacionados:** 
+  [Creating a dashboard with Quick](https://github.com/aws-samples/amazon-quicksight-sdk-proserve) 

# PERF05-BP02 Use soluções de monitoramento para entender as áreas em que o desempenho é mais crítico
<a name="perf_process_culture_use_monitoring_solutions"></a>

 Entenda e identifique áreas em que aumentar a performance de sua workload causará um impacto positivo sobre a eficiência ou a experiência do cliente. Por exemplo, um site que tenha muita interação com o cliente se beneficiaria do uso de serviços de borda para aproximar a entrega de conteúdo dos clientes. 

 **Antipadrões comuns:** 
+  Você pressupõe que as métricas de computação padrão, como utilização de CPU ou pressão de memória, são suficientes para detectar problemas de performance. 
+  Você só usa as métricas comuns registradas pelo software de monitoramento selecionado. 
+  Você só revisa as métricas quando há um problema. 

 **Benefícios de estabelecer esta prática recomendada:** Compreender áreas críticas de desempenho ajuda os proprietários de workloads a monitorar KPIs e priorizar melhorias de alto impacto. 

 **Nível de risco exposto se essa prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Configure um rastreamento completo para identificar padrões de tráfego, latência e áreas de desempenho críticas. Monitore os padrões de acesso aos dados para consultas lentas ou dados particionados e fragmentados incorretamente. Identifique as áreas de restrição da workload usando o teste ou monitoramento de carga. 

 aumentar a eficiência do desempenho entendendo sua arquitetura, os padrões de tráfego e os padrões de acesso aos dados, além de identificar os tempos de latência e processamento. Identificar possíveis gargalos que possam afetar a experiência do cliente com o crescimento da workload. Depois de investigar essas áreas, veja qual solução você pode implantar para eliminar esses problemas de desempenho. 

### Etapas da implementação
<a name="implementation-steps"></a>

1.  Configure um monitoramento completo para capturar todos os componentes e as métricas da workload. Aqui estão alguns exemplos de soluções de monitoramento na AWS.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/perf_process_culture_use_monitoring_solutions.html)

1.  Realize testes para gerar métricas, identificar padrões de tráfego, gargalos e áreas de desempenho críticas. Aqui estão alguns exemplos de como realizar testes: 
   +  Configure o [Canários sintéticos do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) para imitar programaticamente as atividades do usuário baseadas no navegador usando trabalhos cron do Linux ou expressões de taxa para gerar métricas consistentes ao longo do tempo. 
   +  Use o [Testes de carga distribuída da AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) para gerar tráfego de pico ou testar a workload na taxa de crescimento esperada. 

1.  Avalie as métricas e a telemetria para identificar as áreas de desempenho críticas. Avalie essas áreas com sua equipe para discutir sobre o monitoramento e as soluções visando evitar gargalos. 

1.  Experimente melhorias de desempenho e meça essas alterações com dados. Por exemplo, você pode usar o [CloudWatch Evidently](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html) para testar novas melhorias e impactos na performance da workload. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon Builders’ Library](https://aws.amazon.com/builders-library) 
+  [Documentação do X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+  [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 
+  [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) 

 **Vídeos relacionados:** 
+  [The Amazon Builders’ Library: 25 years of Amazon operational excellence](https://www.youtube.com/watch?v=DSRhgBd_gtw) 
+  [Visual Monitoring of Applications with Amazon CloudWatch Synthetics](https://www.youtube.com/watch?v=_PCs-ucZz7E) 

 **Exemplos relacionados:** 
+  [Measure page load time with Amazon CloudWatch Synthetics (Medição do tempo de carga da página com o Amazon CloudWatch Synthetics)](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance) 
+  [Amazon CloudWatch RUM Web Client (Cliente da web do Amazon CloudWatch RUM)](https://github.com/aws-observability/aws-rum-web) 
+  [X-Ray SDK para Node.js](https://github.com/aws/aws-xray-sdk-node) 
+  [X-Ray SDK para Python](https://github.com/aws/aws-xray-sdk-python) 
+  [X-Ray SDK para Java](https://github.com/aws/aws-xray-sdk-java) 
+  [X-Ray SDK para .Net](https://github.com/aws/aws-xray-sdk-dotnet) 
+  [X-Ray SDK para Ruby](https://github.com/aws/aws-xray-sdk-ruby) 
+  [Daemon do X-Ray](https://github.com/aws/aws-xray-daemon) 
+  [Testes de carga distribuída na AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 

# PERF05-BP03 Defina um processo para melhorar a performance da workload
<a name="perf_process_culture_workload_performance"></a>

 Defina um processo para avaliar novos serviços, padrões de design, tipos de recursos e configurações conforme ficarem disponíveis. Por exemplo, execute testes de performance existentes em novas ofertas de instância para determinar o potencial delas de aprimorar sua carga de trabalho. 

 **Antipadrões comuns:** 
+  Você pressupõe que sua arquitetura atual é estática e não será atualizada ao longo do tempo. 
+  Você apresenta alterações de arquitetura ao longo do tempo sem justificativa de métrica. 

 **Benefícios de estabelecer esta prática recomendada:** Ao definir seu processo para fazer alterações de arquitetura, é possível usar os dados coletados para influenciar o projeto da workload ao longo do tempo. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A performance de sua carga de trabalho tem algumas restrições importantes. Guarde essas restrições para saber que tipos de inovação podem aumentar a performance de sua carga de trabalho. Use essas informações enquanto estiver aprendendo sobre novos serviços ou tecnologias que surgem e identificar maneiras de reduzir restrições ou gargalos. 

 Identifique as principais restrições de desempenho da workload. Documente suas restrições de performance da carga de trabalho para que você saiba quais tipos de inovação podem aprimorar a performance da carga de trabalho. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Identifique seus KPIs de performance da workload conforme descrito em [PERF05-BP01 Estabeleça indicadores-chave de desempenho (KPIs) para medir a integridade e o desempenho da workload](perf_process_culture_establish_key_performance_indicators.md) para basear sua workload. 
+  Use [Ferramentas de observabilidade da AWS](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/aws-observability-tools.html) para coletar métricas de performance e medir KPIs. 
+  Faça uma análise aprofundada para identificar as áreas (como configuração e código da aplicação) na workload que estão com baixa performance, conforme descrito em [PERF05-BP02 Use soluções de monitoramento para entender as áreas em que o desempenho é mais crítico](perf_process_culture_use_monitoring_solutions.md). 
+  Use suas ferramentas de análise e desempenho para identificar a estratégia de otimização de desempenho. 
+  Use ambientes de sandbox ou de pré-produção para validar a eficácia da estratégia. 
+  Implemente as mudanças na produção e monitore constantemente o desempenho da workload. 
+  Documente as melhorias e comunique isso às partes interessadas. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Blog da AWS](https://aws.amazon.com/blogs/) 
+  [Novidades da AWS](https://aws.amazon.com/new/?ref=wellarchitected) 

 **Vídeos relacionados:** 
+  [Canal AWS Events no YouTube](https://www.youtube.com/channel/UCdoadna9HFHsxXWhafhNvKw) 
+  [Canal Online Tech Talks da AWS no YouTube](https://www.youtube.com/user/AWSwebinars) 
+  [Canal da Amazon Web Services no YouTube](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg) 

 **Exemplos relacionados:** 
+  [AWS Github](https://github.com/aws) 
+  [AWS Skill Builder](https://explore.skillbuilder.aws/learn) 

# PERF05-BP04 Faça o teste de carga da workload
<a name="perf_process_culture_load_test"></a>

 Teste sua workload para verificar se ela pode lidar com a carga de produção e identificar qualquer gargalo de desempenho. 

 **Antipadrões comuns:** 
+  Você realiza um teste de carga de peças individuais da workload, mas não toda a workload. 
+  Você realiza um teste de carga em uma infraestrutura que não é igual ao seu ambiente de produção. 
+  Você só realiza testes de carga para a carga esperada e não para além dela, para ajudar a prever onde você pode ter problemas futuros. 
+  Você realiza testes de carga sem consultar a [política de testes do Amazon EC2](https://aws.amazon.com/ec2/testing/) e enviar um formulário de envio de eventos simulados. Isso faz com que o teste não seja executado, pois parece um evento de negação de serviço. 

 **Benefícios de estabelecer esta prática recomendada:** Medir sua performance em um teste de carga mostrará onde você será afetado à medida que a carga aumentar. Com isso você terá a capacidade de antecipar as alterações necessárias antes que elas afetem sua carga de trabalho. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação para implementação
<a name="implementation-guidance"></a>

 O teste de carga na nuvem é um processo para medir o desempenho da workload na nuvem em condições realistas com a carga esperada do usuário. Esse processo envolve o provisionamento de um ambiente de nuvem semelhante ao de produção, o uso de ferramentas de teste de carga para gerar carga e a análise de métricas para avaliar a capacidade da workload de lidar com cargas realistas. Execute os testes de carga usando versões sintéticas ou limpas dos dados de produção (remova informações confidenciais ou de identificação). Realize testes de carga automaticamente como parte de seu pipeline de entrega e compare os resultados a Key Performance Indicators (KPI – Indicadores-chave de performance) e limites predefinidos. Esse processo ajuda você a continuar alcançando o desempenho necessário. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Configure o ambiente de teste com base no ambiente de produção. É possível usar os serviços da AWS para executar ambientes em escala de produção para testar a arquitetura. 
+  Escolha e configure a ferramenta de teste de carga adequada à workload. 
+  Defina os cenários e parâmetros do teste de carga (como duração do teste e número de usuários). 
+  Execute cenários de teste em grande escala. Aproveite a Nuvem AWS para testar a workload e descobrir se há uma falha na escala ou se ela está com a escala reduzida horizontalmente de maneira não linear. Por exemplo, use instâncias spot para gerar cargas a um baixo custo e descobrir gargalos antes que eles ocorram em produção. 
+  Monitore e registre métricas de desempenho (como throughput e tempo de resposta). O Amazon CloudWatch pode coletar métricas entre os recursos em sua arquitetura. Você também pode coletar e publicar métricas personalizadas para descobrir métricas de negócio ou derivadas. 
+  Analise os resultados para identificar gargalos de desempenho e áreas para melhorias. 
+  Documente e relate o processo e os resultados do teste de carga. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
+  [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 
+  [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [Testes de carga distribuída na AWS](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/welcome.html) 

 **Vídeos relacionados:** 
+  [Solving with AWS Solutions: Distributed Load Testing](https://www.youtube.com/watch?v=Y-2rk0sSyOM) 
+  [Optimize applications through Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y) 
+  [Demo of Amazon CloudWatch Synthetics (Demonstração do Amazon CloudWatch Synthetics)](https://www.youtube.com/watch?v=hF3NM9j-u7I) 

 **Exemplos relacionados:** 
+  [Testes de carga distribuída na AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 

# PERF05-BP05 Use a automação para corrigir proativamente problemas relacionados ao desempenho
<a name="perf_process_culture_automation_remediate_issues"></a>

 Use os indicadores-chave de performance (KPIs), aliados a sistemas de monitoramento e alerta, para abordar proativamente problemas relacionados à performance. 

 **Antipadrões comuns:** 
+  Você só permite que a equipe de operações faça alterações operacionais na workload. 
+  Você permite todos os filtros de alarmes para a equipe de operações, sem correção proativa. 

 **Benefícios de estabelecer esta prática recomendada:** A correção proativa de ações de alarme permite que a equipe de suporte se concentre nos itens que não são acionáveis automaticamente. Isso ajuda a equipe de operações a lidar com todos os alarmes sem ficar sobrecarregada e, em vez disso, se concentrar apenas nos alarmes críticos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Sempre que possível, use alarmes para desencadear ações automatizadas visando corrigir problemas. Se a resposta automatizada não for possível, encaminhe o alarme para aqueles capazes de responder. Por exemplo, você pode ter um sistema capaz de prever os valores de indicadores-chave de desempenho (KPI) esperados e emitir um alarme quando eles ultrapassarem determinados limites, ou uma ferramenta capaz de interromper ou reverter automaticamente as implantações caso os KPIs estejam fora dos valores esperados. 

 Implemente processos que deem visibilidade à performance conforme sua carga de trabalho estiver sendo executada. Para determinar se a performance da carga de trabalho é ideal, crie painéis de monitoramento e estabeleça normas de linha de base para as expectativas de performance. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  Identifique e compreenda o problema de desempenho que pode ser corrigido automaticamente. Use soluções de monitoramento da AWS, como o [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) ou o AWS X-Ray, para ajudar você a entender melhor a causa raiz do problema. 
+  Crie um plano e um processo de correção detalhados que possam ser usados para corrigir automaticamente o problema. 
+  Configure o gatilho para iniciar automaticamente o processo de correção. Por exemplo, você pode definir um acionador para reiniciar automaticamente uma instância quando ela atinge determinado limite de utilização da CPU. 
+  Use serviços e tecnologias da AWS para automatizar o processo de correção. Por exemplo: [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) fornece uma maneira segura e escalável de automatizar o processo de correção. 
+  Teste o processo de correção automatizado em um ambiente de pré-produção. 
+  Após o teste, implemente o processo de correção no ambiente de produção e monitore constantemente para identificar áreas de melhoria. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Documentação do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [Parceiros da AWS Partner Network de monitoramento, registro em log e performance](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+  [Documentação do X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+  [Using Alarms and Alarm Actions in CloudWatch](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html) 

 **Vídeos relacionados:** 
+  [Intelligently automating cloud operations (Automatizar de forma inteligente as operações na nuvem)](https://www.youtube.com/watch?v=m0S8eAF0l54) 
+  [Setting up controls at scale in your AWS environment](https://www.youtube.com/watch?v=NkE9_okfPG8) 
+  [Automating patch management and compliance using AWS](https://www.youtube.com/watch?v=gL3baXQJvc0) 
+  [How Amazon uses better metrics for improved website performance (Como a Amazon usa métricas melhores para aprimorar o desempenho do site)](https://www.youtube.com/watch?v=_uaaCiyJCFA&ab_channel=AWSEvents) 

 **Exemplos relacionados:** 
+  [CloudWatch Logs Customize Alarms](https://github.com/awslabs/cloudwatch-logs-customize-alarms) 

# PERF05-BP06 Mantenha a workload e os serviços atualizados
<a name="perf_process_culture_keep_workload_and_services_up_to_date"></a>

 Atualize-se com relação aos novos serviços e atributos de nuvem para adotar recursos eficientes, remover problemas e melhorar a eficiência geral do desempenho da workload. 

 **Antipadrões comuns:** 
+  Você pressupõe que sua arquitetura atual é estática e não será atualizada ao longo do tempo. 
+  Você não tem nenhum sistema ou ritmo regular para avaliar se software ou pacotes atualizados são compatíveis com sua workload. 

 **Benefícios de estabelecer esta prática recomendada:** Ao estabelecer um processo para se atualizar sobre novos serviços e ofertas, você pode adotar novos atributos e recursos, resolver problemas e melhorar a performance da workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Avalie maneiras de melhorar o desempenho conforme são disponibilizados novos serviços, padrões de design e atributos de produtos. Determine quais deles poderiam aprimorar o desempenho ou aumentar a eficiência da workload por meio de avaliações, discussões internas ou análises externas. Defina um processo para avaliar atualizações, novos recursos e serviços relevantes para sua workload. Por exemplo, crie uma prova de conceito que use novas tecnologias ou consulte um grupo interno. Ao testar novas ideias ou serviços, execute testes de desempenho para medir o impacto que eles têm sobre o desempenho da workload. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Fazer o inventário de software e arquitetura da workload e identificar os componentes que precisam ser atualizados. 
+  Identifique novidades e atualize fontes relacionadas aos componentes da workload. Por exemplo, você pode se inscrever no [What’s New at AWS](https://aws.amazon.com/new/) para os produtos que correspondem ao componente da workload. Você pode assinar o feed RSS ou gerenciar suas [assinaturas de e-mail](https://pages.awscloud.com/communication-preferences.html). 
+  Defina um cronograma para avaliar novos serviços e atributos para a workload. 
  +  Você pode usar o [inventário do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html) para coletar metadados de sistema operacional (SO), aplicação e instância das instâncias do Amazon EC2 e entender rapidamente quais instâncias executam o software e as configurações exigidas pela política de software e quais instâncias precisam ser atualizadas. 
+  Entenda como atualizar os componentes de sua workload. Aproveite a agilidade da nuvem para testar rapidamente como novos atributos podem melhorar a workload com o intuito de obter eficiências de performance. 
+  Use automação no processo de atualização para reduzir o nível de esforço para implantar novos recursos e limitar erros causados por processos manuais. 
  +  Você pode usar o [CI/CD](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/) para atualizar automaticamente AMIs, imagens de contêiner e outros artefatos relacionados à aplicação de nuvem. 
  +  Você pode usar ferramentas, como [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) para automatizar o processo de atualizações do sistema e programar a atividade usando [Janelas de Manutenção do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html). 
+  Documente seu processo para avaliar atualizações e novos serviços. Forneça aos proprietários o tempo e o espaço necessários para pesquisar, testar, experimentar e validar atualizações e novos serviços. Consulte novamente os KPIs e requisitos empresariais documentados para ajudar a priorizar qual atualização trará um impacto positivo à empresa. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Blog da AWS](https://aws.amazon.com/blogs/) 
+  [Novidades da AWS](https://aws.amazon.com/new/?ref=wellarchitected) 

 **Vídeos relacionados:** 
+  [Canal AWS Events no YouTube](https://www.youtube.com/channel/UCdoadna9HFHsxXWhafhNvKw) 
+  [Canal Online Tech Talks da AWS no YouTube](https://www.youtube.com/user/AWSwebinars) 
+  [Canal da Amazon Web Services no YouTube](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg) 

 **Exemplos relacionados:** 
+  [Laboratórios do Well-Architected: Gerenciamento de inventário e patches](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/) 
+  [Laboratório: AWS Systems Manager](https://mng.workshop.aws/ssm.html) 

# PERF05-BP07 Analise as métricas regularmente
<a name="perf_process_culture_review_metrics"></a>

 Como parte da manutenção de rotina, ou em resposta a eventos ou incidentes, analise as métricas que são coletadas. Use essas análises para identificar quais métricas foram essenciais para resolver problemas e quais métricas adicionais poderiam ajudar a identificar, resolver ou prevenir problemas se estivessem sendo acompanhadas. 

 **Antipadrões comuns:** 
+  Você permite que as métricas permaneçam em um estado de alarme por um período prolongado. 
+  Você cria alarmes que não são acionáveis por um sistema de automação. 

 **Benefícios de estabelecer esta prática recomendada:** Analise continuamente as métricas que estão sendo coletadas para garantir que identifiquem, resolvam ou evitem problemas corretamente. As métricas também podem se tornar obsoletas se você permitir que elas permaneçam em um estado de alarme por um período prolongado. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Melhore constantemente a coleta e o monitoramento de métricas. Como parte da resposta a incidentes ou eventos, avalie as métricas que foram úteis para resolver o problema e quais poderiam ter ajudado, mas não estão sendo acompanhadas no momento. Use este método para aprimorar a qualidade das métricas coletadas, de modo que você possa prevenir ou resolver incidentes futuros mais rapidamente. 

 Como parte da resposta a incidentes ou eventos, avalie as métricas que foram úteis para resolver o problema e quais poderiam ter ajudado, mas não estão sendo acompanhadas no momento. Use esses dados para aprimorar a qualidade das métricas coletadas, de modo que você possa prevenir ou resolver incidentes futuros mais rapidamente. 

### Etapas da implementação
<a name="implementation-steps"></a>

1. Defina métricas essenciais de desempenho a serem monitoradas que estejam alinhadas ao seu objetivo de workload. 

1. Defina uma linha de base e um valor desejável para cada métrica. 

1. Defina uma frequência (como semanal ou mensal) para revisar as métricas essenciais. 

1. Durante cada revisão, avalie as tendências e o desvio dos valores base. Procure gargalos ou anomalias de desempenho. 

1. Para os problemas identificados, realize uma análise aprofundada da causa raiz para entender o principal motivo do problema. 

1. Documente as descobertas e use estratégias para lidar com os problemas e gargalos identificados. 

1. Avalie e melhore constantemente o processo de revisão de métricas.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Documentação do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [Collect metrics and logs from Amazon EC2 Instances and on-premises servers with the CloudWatch Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected) 
+  [Parceiros da AWS Partner Network de monitoramento, registro em log e performance](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+  [Documentação do X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 

 **Vídeos relacionados:** 
+  [Setting up controls at scale in your AWS environment](https://www.youtube.com/watch?v=NkE9_okfPG8) 
+  [How Amazon uses better metrics for improved website performance (Como a Amazon usa métricas melhores para aprimorar o desempenho do site)](https://www.youtube.com/watch?v=_uaaCiyJCFA&ab_channel=AWSEvents) 

 **Exemplos relacionados:** 
+  [Creating a dashboard with Quick](https://github.com/aws-samples/amazon-quicksight-sdk-proserve) 
+  [Level 100: Monitoring with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) 

# Otimização de custos
<a name="a-cost-optimization"></a>

O pilar Otimização de custos inclui a capacidade de executar sistemas para proporcionar valor comercial pelo menor preço. Você pode encontrar orientações prescritivas sobre implementação no [whitepaper sobre o pilar de otimização de custos](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html?ref=wellarchitected-wp).

**Topics**
+ [Pratique o gerenciamento financeiro na nuvem](a-practice-cloud-financial-management.md)
+ [Reconhecimento de despesas e usos](a-expenditure-and-usage-awareness.md)
+ [Recursos econômicos](a-cost-effective-resources.md)
+ [Gerenciar recursos de demanda e fornecimento](a-manage-demand-and-supply-resources.md)
+ [Otimizar ao longo do tempo](a-optimize-over-time.md)

# Pratique o gerenciamento financeiro na nuvem
<a name="a-practice-cloud-financial-management"></a>

**Topics**
+ [CUSTOS 1. Como implementar o gerenciamento financeiro na nuvem?](cost-01.md)

# CUSTOS 1. Como implementar o gerenciamento financeiro na nuvem?
<a name="cost-01"></a>

A implementação do gerenciamento financeiro na nuvem ajuda as organizações a obterem valor empresarial e sucesso financeiro à medida que otimizam os custos e o uso e escalam na AWS.

**Topics**
+ [COST01-BP01 Estabelecer a propriedade da otimização de custos](cost_cloud_financial_management_function.md)
+ [COST01-BP02 Estabelecer uma parceria entre finanças e tecnologia](cost_cloud_financial_management_partnership.md)
+ [COST01-BP03 Estabelecer orçamentos e previsões de nuvem](cost_cloud_financial_management_budget_forecast.md)
+ [COST01-BP04 Implemente o reconhecimento de custos em seus processos organizacionais](cost_cloud_financial_management_cost_awareness.md)
+ [COST01-BP05 Relatar e notificar sobre a otimização de custos](cost_cloud_financial_management_usage_report.md)
+ [COST01-BP06 Monitore custos proativamente](cost_cloud_financial_management_proactive_process.md)
+ [COST01-BP07 Manter-se atualizado com os novos lançamentos de serviços](cost_cloud_financial_management_scheduled.md)
+ [COST01-BP08 Criar uma cultura com reconhecimento de custos](cost_cloud_financial_management_culture.md)
+ [COST01-BP09 Quantificar o valor comercial proveniente da otimização de custos](cost_cloud_financial_management_quantify_value.md)

# COST01-BP01 Estabelecer a propriedade da otimização de custos
<a name="cost_cloud_financial_management_function"></a>

 Crie uma equipe (Escritório de Negócios na Nuvem, Centro de Excelência da Nuvem ou equipe FinOps) responsável por estabelecer e manter o reconhecimento de custos em toda a organização. O responsável pela otimização de custos pode ser uma pessoa ou uma equipe (requer pessoal das equipes de finanças, tecnologia e negócios) que conheça toda a organização e as finanças da nuvem. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Esta é a introdução de uma função ou uma equipe de Escritório de Negócios na Nuvem (CBO) ou Centro de Excelência da Nuvem (CCOE) responsável por estabelecer e manter uma cultura de reconhecimento de custos de computação em nuvem. Em toda a organização, essa função pode ser exercida por qualquer pessoa ou equipe existente, ou por uma nova equipe com as principais partes interessadas em finanças, tecnologia e organização. 

 A função (individual ou equipe) prioriza e gasta a porcentagem necessária de seu tempo em atividades de gerenciamento e otimização de custos. Para uma organização pequena, a função pode gastar uma porcentagem de tempo menor em comparação com uma função de tempo integral para uma empresa maior. 

 Essa função (individual ou em equipe) prioriza e gasta a porcentagem necessária de seu tempo em atividades de gerenciamento e otimização de custos. Para uma organização pequena, a função pode gastar uma porcentagem menor de tempo em atividades de gerenciamento e otimização de custos em comparação com uma função de tempo integral de uma empresa maior. 

 A função exige uma abordagem multidisciplinar, com recursos de gerenciamento de projetos, ciência de dados, análise financeira e desenvolvimento de software ou infraestrutura. Ela pode melhorar a eficiência da workload realizando otimizações de custos em três propriedades diferentes: 
+  **Centralizado:** por meio de equipes designadas, como a equipe FinOps, a equipe de Gerenciamento Financeiro na Nuvem (CFM), o Escritório de Negócios na Nuvem (CBO) ou o Centro de Excelência da Nuvem (CCoE), os clientes podem projetar e implementar mecanismos de governança e promover as práticas recomendadas em toda a empresa. 
+  **Descentralizado:** as equipes de tecnologia são convencidas a realizar otimizações de custos. 
+  **Híbrido:** combinação de equipes centralizadas e descentralizadas podem trabalhar em conjunto para realizar otimizações de custo. 

 A função pode ser medida ao comparar a sua capacidade de realização e entrega com as metas de otimização de custos (por exemplo, métricas de eficiência da workload). 

 Você deve garantir que haja patrocínio executivo para essa função, o que é um fator de sucesso fundamental. O patrocinador é considerado defensor do consumo de nuvem econômico e oferece suporte ao encaminhamento para a equipe a fim de garantir que as atividades de otimização de custos sejam tratadas de acordo com o nível de prioridade definido pela organização. Caso contrário, a orientação pode ser ignorada e as oportunidades de redução de custo não serão priorizadas. Juntos, o patrocinador e a equipe ajudam a organização a consumir a nuvem com eficiência e agregar valor comercial. 

 Se você tem um plano de suporte Business, Enterprise-On-Ramp [ou Enterprise](https://aws.amazon.com/premiumsupport/plans/) e precisa de ajuda para formar essa equipe ou função, entre em contato com especialistas em Cloud Financial Management (CFM) por meio de sua equipe de contas. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Defina os membros principais:** todas as partes relevantes da organização devem contribuir e ter interesse pelo gerenciamento de custos. As equipes comuns dentro das organizações geralmente incluem: finanças, proprietários de aplicações ou produtos, gerenciamento e equipes técnicas (DevOps). Alguns são contratados em tempo integral (financeiro ou técnico), enquanto outros são contratados periodicamente, conforme necessário. Pessoas ou equipes encarregadas de executar o CFM precisam dos seguintes conjuntos de habilidades: 
  +  **Desenvolvimento de software:** no caso em que scripts e automação estão sendo criados. 
  +  **Engenharia de infraestrutura:** para implantar scripts, automatizar processos e entender como os serviços e os recursos são provisionados. 
  +  **Perspicácia operacional:** o intuito do CFM é permitir a operação eficiente na nuvem ao medir, monitorar, planejar e escalar o uso eficiente da nuvem. 
+  **Definir metas e métricas: **a função precisa agregar valor à organização de diferentes formas. Esses objetivos são definidos e evoluem continuamente com a organização. As atividades comuns incluem: criação e execução de programas educacionais sobre otimização de custos em toda a organização, desenvolvimento de padrões em toda a organização (como monitoramento e geração de relatórios para otimização de custos) e definição de metas de workload sobre otimização. Essa função também precisa informar regularmente a organização sobre o recurso de otimização de custos. 

   Você pode definir indicadores-chave de performance (KPIs) baseados em valor ou custo. Ao definir os KPIs, você pode calcular o custo esperado em termos de eficiência e o resultado comercial esperado. KPIs baseados em valor vinculam métricas de uso e custo a motivadores de valor empresarial e ajudam a racionalizar mudanças em gastos na AWS. O primeiro passo para derivar KPIs baseados em valor é trabalhar em conjunto, em toda a organização, para selecionar e concordar sobre um conjunto padrão de KPIs. 
+  **Estabelecer um ritmo regular:** o grupo (equipes financeira, empresarial e de tecnologia) devem se reunir regularmente para analisar metas e métricas. Um ritmo típico envolve analisar o estado da organização, todos os programas em execução no momento e as métricas financeiras e de otimização gerais. Depois, as principais workloads são relatadas em mais detalhes. 

   Durante essas revisões regulares, você pode analisar a eficiência (custo) da workload e o resultado empresarial. Por exemplo, um aumento de 20% no custo de uma workload pode ser consequência de um aumento do uso pelos clientes. Neste caso, esse aumento de 20% no custo pode ser interpretado como um investimento. Essas chamadas regulares podem ajudar as equipes a identificar KPIs de valor que ofereçam propósito para toda a organização. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Blog de CCoE da AWS](https://aws.amazon.com/blogs/enterprise-strategy/tag/ccoe/) 
+  [Criar um Escritório de Negócios na Nuvem](https://aws.amazon.com/blogs/enterprise-strategy/creating-the-cloud-business-office/) 
+  [CCoE: Centro de Excelência da Nuvem](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html) 

 **Vídeos relacionados:** 
+ [Vanguard CCOE Success Story (História de sucesso de CCoE de vanguarda)](https://www.youtube.com/watch?v=0XA08hhRVFQ)

 **Exemplos relacionados:** 
+ [Usar um Centro de Excelência da Nuvem (CCoE) para transformar toda a empresa](https://aws.amazon.com/blogs/enterprise-strategy/using-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise/)
+ [Criar um CCoE para transformar toda a empresa](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/building-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise.html)
+ [7 obstáculos que devem ser evitados ao criar um CCoE](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/)

# COST01-BP02 Estabelecer uma parceria entre finanças e tecnologia
<a name="cost_cloud_financial_management_partnership"></a>

Envolva equipes financeiras e de tecnologia em discussões sobre custo e uso em todas as etapas da jornada para a nuvem. As equipes se reúnem e discutem regularmente assuntos como objetivos e metas organizacionais, o estado atual de custo e uso e práticas financeiras e contábeis. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

as equipes de tecnologia inovam mais rapidamente na nuvem devido à redução dos ciclos de implantação de aprovação, aquisição e infraestrutura. Isso pode ser um ajuste para organizações financeiras anteriormente usadas para executar processos demorados e com uso intensivo de recursos para aquisição e implantação de capital em ambientes de datacenter no local, além de alocação de custos apenas na aprovação do projeto. 

Do ponto de vista da organização financeira e de aquisição, o processo de definição orçamentária, solicitações de capital, aprovações, aquisição e instalação de infraestrutura física é algo que levou décadas para ser aprendido e padronizado:
+ Equipes de engenharia ou TI costumam ser os solicitantes
+ Várias equipes financeiras atuam como aprovadores e compradores
+ Equipes de operação estendem, acumulam e disponibilizam infraestrutura pronta para ser usada

![\[Circular workflow diagram showing technology teams, procurement, supply chain, and operations interactions.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/cost01-bp02-finance-and-procurement-workflow.png)


Com a adoção da nuvem, a aquisição e o consumo de infraestrutura deixaram de estar vinculados a uma série de dependências. No modelo de nuvem, as equipes de tecnologia e produto deixam de ser simples desenvolvedoras, passando a ser operadoras e proprietárias de seus produtos, responsáveis pela maioria das atividades historicamente associadas às equipes financeiras e de operações, incluindo aquisição e implantação.

Basta uma conta de usuário e o conjunto adequado de permissões para provisionar recursos na nuvem. Também é isso que reduz o risco financeiro e de TI, o que significa que as equipes estão sempre a poucos cliques ou chamadas de API de encerrar recursos ociosos ou desnecessários na nuvem. Também é isso que permite que as equipes de tecnologia inovem com mais rapidez: a agilidade e capacidade de aplicar e derrubar experimentos. Embora a natureza variável do consumo na nuvem possa afetar a previsibilidade do ponto de vista de previsão e definição orçamentária, a nuvem oferece às organizações a capacidade de reduzir o custo de provisionamento em excesso, além de reduzir o custo de oportunidade associado ao subprovisionamento conservador.

![\[Diagram showing Technology and Product teams deploying, Finance and Business teams operating, with optimization at the center.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/cost01-bp02-deploy-operate-optimize.png)


Estabelecer uma parceria entre as principais partes interessadas em finanças e tecnologia para criar uma compreensão compartilhada dos objetivos organizacionais e desenvolver mecanismos para obter sucesso financeiro no modelo de gastos variáveis da computação em nuvem. As equipes relevantes da sua organização devem estar envolvidas em discussões de custo e uso em todas as fases da jornada para a nuvem, incluindo: 
+ ** Líderes financeiros:** CFOs, controladores financeiros, planejadores financeiros, analistas de negócios, aquisições, sourcing e contas a pagar devem compreender o modelo de nuvem de consumo, as opções de compra e o processo de faturamento mensal. O departamento financeiro precisa se unir às equipes de tecnologia para criar e socializar uma narrativa de valor de TI, ajudando as equipes comerciais a entender como o gasto com tecnologia está associado aos resultados comerciais. Assim, as despesas com tecnologia são vistas não como custos, e sim como investimentos. Devido às diferenças fundamentais entre a nuvem (como a taxa de alteração no uso, definição de preço com pagamento conforme o uso, definição de preço em camadas, modelos de definição de preço e informações detalhadas de faturamento e uso) em comparação à operação no local, é essencial que a organização financeira entenda como o uso da nuvem pode afetar aspectos empresariais, incluindo processos de aquisição, rastreamento de incentivos, alocação de custos e demonstrações financeiras.
+  **Líderes de tecnologia:** os líderes de tecnologia (incluindo proprietários de produtos e aplicativos) devem estar cientes dos requisitos financeiros (por exemplo, restrições orçamentárias), bem como dos requisitos de negócios (por exemplo, contratos de nível de serviço). Isso permite que a carga de trabalho seja implementado para atingir os objetivos desejados da organização. 

A parceria entre finanças e tecnologia oferece os seguintes benefícios: 
+ As equipes de finanças e tecnologia têm visibilidade praticamente em tempo real dos custos e do uso.
+ As equipes de finanças e tecnologia estabelecem um procedimento operacional padrão para lidar com a variação de gastos na nuvem.
+ As partes interessadas nas finanças atuam como consultores estratégicos com relação à forma como o capital é usado para comprar descontos de compromissos (por exemplo, instâncias reservadas ou Savings Plans da AWS) e como a nuvem é usada para expandir a organização. 
+ Contas a pagar e processos de aquisição existentes são usados com a nuvem.
+ As equipes de finanças e tecnologia colaboram na previsão de custos e uso futuros da AWS para alinhar e criar orçamentos organizacionais. 
+ Melhor comunicação entre organizações por meio de uma linguagem compartilhada e entendimento comum dos conceitos financeiros.

As partes interessadas adicionais dentro da sua organização que devem ser envolvidas em discussões de custo e uso incluem: 
+ **Proprietários de unidades de negócios:** os proprietários de unidades de negócios devem compreender o modelo de negócios de nuvem para que possam fornecer orientações tanto para as unidades de negócios quanto para toda a empresa. Esse conhecimento de nuvem é essencial quando há necessidade de prever o crescimento e o uso da carga de trabalho, e ao avaliar opções de compra de longo prazo, como instâncias reservadas ou Savings Plans. 
+ **Equipe de engenharia: **uma parceria entre as equipes financeira e de tecnologia é essencial para o desenvolvimento de uma cultura de consciência dos custos que encoraja os engenheiros a agirem em relação ao gerenciamento financeiro na nuvem (CFM). Um dos problemas comuns dos profissionais de CFM ou operações financeiras e das equipes financeiras é fazer com que os engenheiros entendam todos os negócios na nuvem, sigam as práticas recomendadas e tomem as medidas recomendadas.
+ **Terceiros: **se sua organização usa terceiros (por exemplo, consultores ou ferramentas), certifique-se de que eles estejam alinhados com seus objetivos financeiros e possam demonstrar o alinhamento por meio de seus modelos de engajamento e um retorno sobre o investimento (ROI). Terceiros normalmente contribuirão para o relatório e a análise de qualquer carga de trabalho que gerenciem e fornecerão análise de custo de qualquer carga de trabalho que projetem.

Implementar o CFM e obter sucesso requer a colaboração das equipes financeira, comercial e de tecnologia, além de uma mudança na forma como os gastos com nuvem são comunicados e avaliados em toda a organização. Inclua as equipes de engenharia para que façam parte dessas conversas sobre custos e uso em todos os estágios, incentivando-as a seguir as práticas recomendadas e tomar medidas previamente acordadas conforme for apropriado.

**Etapas da implementação**
+ **Defina os membros principais: **Verifique se todos os membros relevantes de suas equipes de finanças e tecnologia participam da parceria. Os membros financeiros relevantes serão aqueles que interagem com a conta da nuvem. Normalmente serão CFOs, controladores financeiros, planejadores financeiros, analistas de negócios, compras e sourcing. Normalmente, os membros de tecnologia serão proprietários de produtos e aplicativos, gerentes técnicos e representantes de todas as equipes que criam na nuvem. Outros membros podem incluir proprietários de unidades de negócios, como marketing que influenciará o uso de produtos, e terceiros, como consultores para alcançar o alinhamento com seus objetivos e mecanismos e para auxiliar na geração de relatórios.
+ **Definir tópicos para discussão:** Defina os tópicos que são comuns entre as equipes ou que precisarão de um entendimento compartilhado. Siga o custo a partir do momento em que ele é criado, até que a fatura seja paga. Observe todos os membros envolvidos e os processos organizacionais que devem ser aplicados. Compreenda cada etapa ou processo que ele passa e as informações associadas, como modelos de definição de preço disponíveis, definição de preço em camadas, modelos de desconto, orçamento e requisitos financeiros.
+ **Estabelecer um ritmo regular: **Para criar uma parceria financeira e tecnológica, estabeleça uma comunicação regular para criar e manter o alinhamento. O grupo precisa se reunir regularmente para comparar objetivos e métricas. Um ritmo típico envolve analisar o estado da organização, todos os programas em execução no momento e as métricas financeiras e de otimização gerais. Em seguida, as principais workloads são relatadas em mais detalhes.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Blog de novidades da AWS](https://aws.amazon.com/blogs/aws/) 

# COST01-BP03 Estabelecer orçamentos e previsões de nuvem
<a name="cost_cloud_financial_management_budget_forecast"></a>

 Ajuste os processos de previsão e orçamento organizacional existentes para que sejam compatíveis com a natureza altamente variável dos custos e uso da nuvem. Os processos devem ser dinâmicos, usando algoritmos baseados em tendências ou em orientadores de negócios, ou uma combinação deles. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Os clientes usam a nuvem para obter eficiência, velocidade e agilidade, o que cria uma quantidade altamente variável de custo e utilização. Os custos podem diminuir (ou, às vezes, aumentar) à medida que a workload ganha eficiência ou que novas workloads e atributos são implantados. As workloads podem escalar para atender mais clientes, o que aumenta a utilização e os custos da nuvem. Os recursos estão mais acessíveis do que nunca. A elasticidade da nuvem também traz elasticidade para os custos e as previsões. Os processos de orçamento organizacional existentes devem ser modificados para incorporar essa variabilidade. 

 Geralmente, o orçamento é preparado para um único ano e permanece fixo, exigindo adesão estrita de todos os envolvidos. Entretanto, a previsão é mais flexível, permitindo reajustes ao longo do ano e fornecendo projeções dinâmicas em um período de um, dois ou três anos. Tanto o orçamento quanto a previsão desempenham um papel fundamental para estabelecer expectativas financeiras entre várias partes interessadas em tecnologia e negócios. A precisão da previsão e implementação também impõe responsabilidade às partes interessadas que já são diretamente responsáveis pelo custo de provisionamento, e isso também pode contribuir para o reconhecimento geral de custos. 

 Ajuste os processos de orçamento e previsão em vigor para que se tornem mais dinâmicos por meio de um algoritmo baseado em tendências (usando custos históricos como entradas) ou de algoritmos baseados em motivadores (por exemplo, lançamentos de produtos, expansão regional ou novos ambientes para workloads), que são ideais para um ambiente de gastos dinâmico e variável, ou de uma combinação de tendências e motivadores empresariais. 

 Você pode usar o [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) para previsões baseadas em tendências em um período futuro definido com base no gasto no passado. O mecanismo de previsão do AWS Cost Explorer segmenta os dados históricos com base em tipos de cobrança (por exemplo, instâncias reservadas) e usa uma combinação de machine learning e modelos baseados em regras com a finalidade de prever os gastos individualmente para todos os tipos de cobrança. 

 Identifique os motivadores empresariais que podem afetar o custo de uso e faça uma previsão para cada um deles separadamente a fim de garantir que o uso esperado seja calculado com antecedência. Alguns dos motivadores estão vinculados às equipes de TI e de produtos da organização. Outros motivadores empresariais, como eventos de marketing, promoções, fusões e aquisições, são conhecidos por seus líderes de vendas, marketing e negócios, e é importante colaborar e considerar também todos esses motivadores de demanda. Você precisa trabalhar com eles de perto para entender o impacto nos novos motivadores internos. 

 Depois de determinar sua previsão baseada em tendências usando o Cost Explorer ou qualquer outra ferramenta, use o [AWS Calculadora de Preços](https://calculator.aws/#/) para estimar os custos do caso de uso da AWS e os custos futuros com base no uso esperado (tráfego, solicitações por segundo, instância do Amazon EC2 necessária). Você também pode usá-lo para planejar seus gastos, identificar oportunidades de economia e tomar decisões informadas ao usar a AWS. É importante monitorar quão precisa é essa previsão, pois os orçamentos devem ser definidos com base nesses cálculos e estimativas. 

 Use [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) para definir orçamentos personalizados e detalhados especificando o período, a recorrência ou a quantidade (fixa ou variável) e adicionando filtros, como serviço, Região da AWS e tags. Para manter-se informado sobre a performance de orçamentos existentes, você pode criar e programar [relatórios do AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/reporting-cost-budget.html) para você e para as partes interessadas. Você também pode criar [alertas do AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html) com base nos custos reais, cuja natureza é reativa, ou com base nos custos previstos, o que oferece tempo para implementar mitigações de possíveis excessos de custos. Você pode receber um alerta quando exceder o custo ou uso, ou se houver previsão de que exceda a quantia orçada. 

 Use [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) para evitar ou reduzir custos inesperados e aprimorar o controle sem prejudicar a inovação. O AWS Cost Anomaly Detection utiliza machine learning para identificar gastos anômalos e causas-raiz, para que você possa agir rapidamente. [Com três etapas simples](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)você pode criar seu próprio monitor contextualizado e receber alertas sempre que qualquer gasto anormal for detectado. 

 Conforme mencionado na seção Parceria de tecnologia e finanças [do pilar de otimização de custos Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/finance-and-technology-partnership.html), é importante ter parceria e ritmo entre TI, departamento financeiro e outras partes interessadas para verificar se todos usam as mesmas ferramentas e processos para manter a consistência. Nas situações em que os orçamentos precisem sofrer alterações, aumentar o ritmo dos pontos de contato pode ajudar na hora de reagir a essas mudanças com mais rapidez. 

### Etapas para a implementação
<a name="implementation-steps"></a>
+  **Analisar a previsão baseada em tendências:** Use as ferramentas preferidas de previsão baseadas em tendências, como o AWS Cost Explorer e o Amazon Forecast. Analise seu custo de uso em diferentes dimensões, como serviço, conta, tags e categorias de custo. Se for necessária uma previsão avançada, importe os dados do AWS Cost and Usage Report para o Amazon Forecast (o que aplica a regressão linear como uma forma de machine learning para que seja feita a previsão). 
+  **Analisar a previsão baseada em motivadores:** identifique o impacto dos motivadores empresariais no uso da nuvem e faça uma previsão para cada um deles separadamente a fim de calcular o custo de uso esperado com antecedência. Trabalhe em estreita colaboração com proprietários de unidades de negócios e partes interessadas para entender o impacto sobre os novos motivadores e calcular as mudanças de custo esperadas para definir orçamentos precisos. 
+  **Atualizar os processos de previsão e orçamento existentes:** defina os processos orçamentários de previsão de acordo com os métodos adotados, como baseado em tendências, baseado em motivadores empresariais ou uma combinação de ambos. Os orçamentos devem ser calculados e realistas, com base nesses processos de previsão. 
+  **Configurar alertas e notificações:** use alertas do AWS Budgets e AWS Cost Anomaly Detection para receber alertas e notificações. 
+  **Realizar revisões regulares com partes interessadas importantes: **por exemplo, partes interessadas nos departamentos de TI, financeiro e plataforma, bem como de outras áreas da empresa, para que se alinhem às mudanças no rumo dos negócios e no uso. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/?sc_channel=cfm-blog&sc_campaign=using-the-right-tools-for-your-cloud-cost-forecasting&sc_medium=plan-and-evaluate&sc_content=cfm-blog&sc_detail=link&sc_outcome=aw&sc_publisher=cfm-awareness&trk=using-the-right-tools-for-your-cloud-cost-forecasting_cfm-blog_link) 
+  [AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) 
+  [Quick Forecasting](https://docs.aws.amazon.com/quicksight/latest/user/forecasts-and-whatifs.html) 
+  [Amazon Forecast](https://aws.amazon.com/forecast/) 
+  [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 
+  [Blog de novidades da AWS](https://aws.amazon.com/blogs/aws/) 

 **Vídeos relacionados:** 
+  [How can I use AWS Budgets to track my spending and usage](https://www.youtube.com/watch?v=Ris23gKc7s0) 
+  [Série de otimização de custos da AWS: AWS Budgets](https://www.youtube.com/watch?v=5vYEVQzoMeM) 

 **Exemplos relacionados:** 
+  [Entenda e crie previsões baseadas em motivadores](https://aws.amazon.com/blogs/aws-cloud-financial-management/understand-and-build-driver-based-forecasting/) 
+  [Como estabelecer e impulsionar uma cultura de previsão](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-establish-and-drive-a-forecasting-culture/) 
+  [Como melhorar sua previsão de custos na nuvem](https://aws.amazon.com/blogs/aws-cloud-financial-management/forecasting-blog-series-1-3-ways-to-more-effectively-forecast-cloud-spend/) 
+  [Uso das ferramentas certas para prever custos na nuvem](https://aws.amazon.com/blogs/aws-cloud-financial-management/using-the-right-tools-for-your-cloud-cost-forecasting/) 

# COST01-BP04 Implemente o reconhecimento de custos em seus processos organizacionais
<a name="cost_cloud_financial_management_cost_awareness"></a>

Implemente o reconhecimento de custos, crie transparência e contabilize os custos em processos novos ou existentes que afetem o uso e aproveite os processos existentes para reconhecimento de custos. Implemente o reconhecimento de custos no treinamento de funcionários. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação de implementação
<a name="implementation-guidance"></a>

O reconhecimento de custos deve ser implementado em processos organizacionais novos e existentes. É um dos recursos fundamentais para outras práticas recomendadas. Recomendamos reutilizar e modificar processos existentes sempre que possível, o que minimiza o impacto na agilidade e velocidade. Informe os custos da nuvem para as equipes de tecnologia e os responsáveis por decisões nas equipes financeira e comercial para conscientizar sobre os custos, e estabeleça indicadores-chave de desempenho (KPIs) para as partes interessadas dos departamentos financeiro e comercial. As recomendações a seguir ajudarão a implementar o reconhecimento de custos em sua carga de trabalho:
+ Verifique se o gerenciamento de mudanças inclui uma medição de custo para quantificar o impacto financeiro das mudanças. Isso ajuda a abordar de forma proativa as preocupações relacionadas a custos e a destacar as economias de custos.
+ Verifique se a otimização de custos é um componente essencial de seus recursos operacionais. Por exemplo, você pode aproveitar os processos existentes de gerenciamento de incidentes para investigar e identificar causas raiz das anomalias de custo e uso ou excessos de custo.
+ Acelere a economia de custos e a obtenção de valor empresarial por meio da automação ou de ferramentas. Ao pensar sobre o custo da implementação, enquadre a conversa para incluir um componente de retorno sobre o investimento (ROI) para justificar o investimento de tempo ou dinheiro.
+ Aloque os custos de nuvem implementando showbacks ou chargebacks de gastos na nuvem, incluindo gastos com opções de compra baseadas em compromissos, serviços compartilhados e compras de marketplace para impulsionar um consumo da nuvem mais consciente sobre custos.
+ Estenda os programas de treinamento e desenvolvimento existentes para incluir treinamento com reconhecimento de custos em toda a organização. Recomendamos que isso inclua treinamento e certificação contínuos. Isso criará uma organização capaz de autogerenciar custos e uso.
+ Aproveite ferramentas nativas e gratuitas da AWS, como [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/), [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)e aos [relatórios do AWS Budgets](https://aws.amazon.com/about-aws/whats-new/2019/07/introducing-aws-budgets-reports/).

Quando as organizações adotam sistematicamente práticas de [Gerenciamento financeiro na nuvem](https://aws.amazon.com/aws-cost-management/) (CFM), esses comportamentos passam a estar enraizados no modo de trabalho e tomada de decisão. O resultado é uma cultura mais consciente em relação aos custos, desde os desenvolvedores que arquitetam uma nova aplicação concebida na nuvem até gerentes financeiros que analisam o ROI desses novos investimentos na nuvem.

**Etapas da implementação**
+ ** Identificar processos organizacionais relevantes: **Cada unidade organizacional analisa os processos que possui e identifica aqueles que afetam o custo e o uso. Todos os processos que resultam na criação ou no encerramento de um recurso precisam ser incluídos para análise. Procure processos que possam sustentar o reconhecimento de custos na empresa, como gerenciamento de incidentes e treinamento. 
+ **Estabeleça uma cultura com reconhecimento de custos autossustentável.** Garanta que todas as partes interessadas relevantes se alinhem ao motivo da mudança e impacto como custo para que entendam os custos da nuvem. Isso vai possibilitar que sua organização estabeleça uma cultura de inovação autossustentável com reconhecimento de custos.
+ ** Atualizar processos com reconhecimento de custos:** Cada processo é modificado para ter reconhecimento de custos. O processo pode exigir pré-verificações adicionais, como avaliação do impacto do custo, ou pós-verificações que validam se as mudanças esperadas no custo e no uso ocorreram. Processos de suporte, como treinamento e gerenciamento de incidentes, podem ser estendidos para incluir itens de custo e uso. 

Para obter ajuda, fale com especialistas em CFM por meio de sua equipe de conta, ou explore os recursos e os documentos relacionados abaixo.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [Gerenciamento financeiro na nuvem da AWS](https://aws.amazon.com/aws-cost-management/)

 **Exemplos relacionados:** 
+  [Estratégia para um gerenciamento eficiente dos custos da nuvem](https://aws.amazon.com/blogs/enterprise-strategy/strategy-for-efficient-cloud-cost-management/) 
+  [Série de blogs sobre controle de custos n.º 3: Como lidar com o impacto dos custos](https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-control-blog-series-3-how-to-handle-cost-shock/) 
+  [Um guia de introdução ao AWS Cost Management](https://aws.amazon.com/blogs/aws-cloud-financial-management/beginners-guide-to-aws-cost-management/) 

# COST01-BP05 Relatar e notificar sobre a otimização de custos
<a name="cost_cloud_financial_management_usage_report"></a>

 Configure orçamentos de nuvem e mecanismos para detectar anomalias no uso. Configure ferramentas relacionadas para alertas de custo e uso em relação a metas predefinidas e receba notificações quando algum uso exceder essas metas. Faça reuniões regulares para analisar a relação custo-benefício das workloads e promover o reconhecimento de custos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação para implementação
<a name="implementation-guidance"></a>

 você deve informar regularmente sobre a otimização de custos e usos dentro da sua organização. Você pode implementar sessões dedicadas para discutir a relação de custo/performance ou incluir a otimização de custos em seus ciclos regulares de relatórios operacionais para as workloads. Use serviços e ferramentas para monitorar a relação de custo/performance regularmente e implementar oportunidades de redução de custos.  

 Visualize o custo e o uso com vários filtros e granularidade usando o [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/), que fornece painéis e relatórios, como custos por serviço ou por conta, custos diários ou custos de mercado. Acompanhe o andamento do custo e do uso em relação aos orçamentos configurados com [relatórios do AWS Budgets](https://aws.amazon.com/about-aws/whats-new/2019/07/introducing-aws-budgets-reports/). 

 Uso [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) para definir orçamentos personalizados e monitorar os custos e o uso, para que possa reagir rapidamente a alertas recebidos via e-mail ou notificações do Amazon Simple Notification Service (Amazon SNS) se o limite for excedido. [Defina seu período de orçamento preferencial](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-create.html) como diário, mensal, trimestral ou anual, e crie limites específicos para se manter informado sobre o progresso do uso e dos custos reais e previstos rumo ao limite do orçamento. Você também pode definir [de emergência](https://docs.aws.amazon.com/cost-management/latest/userguide/sns-alert-chime.html) e [ações](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html) em resposta a esses alertas para que sejam executados automaticamente, ou por meio de um processo de aprovação quando uma meta de orçamento é excedida. 

 Implemente notificações sobre custo e uso para garantir que alterações no custo e no uso possam ser respondidas rapidamente caso não sejam esperadas. [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) permite que você reduza os custos-surpresa e aumente o controle sem desacelerar a inovação. O AWS Cost Anomaly Detection identifica gastos anormais e causas raiz, o que ajuda a reduzir o risco de surpresas no faturamento. Com três etapas simples você pode criar seu próprio monitor contextualizado e receber alertas sempre que qualquer gasto anormal for detectado. 

 Você também pode usar o [Quick](https://aws.amazon.com/quicksight/) com dados do AWS Cost and Usage Report (CUR) para fornecer relatórios altamente personalizados com dados mais granulares. O Quick permite programar relatórios e receber e-mails periódicos sobre o relatório de custos com o histórico de custos e uso, ou oportunidades de economia de custo. Confira nossa solução de [painel de inteligência de custos](https://aws.amazon.com/blogs/aws-cloud-financial-management/a-detailed-overview-of-the-cost-intelligence-dashboard/) (CID) integrada ao Quick, que oferece visibilidade avançada. 

 Use [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/), que oferece orientação para verificar se os recursos provisionados se alinham com as práticas recomendadas da AWS para otimização de custo. 

 Verifique as recomendações de Savings Plans por meio de grafos visuais em comparação com o custo e uso detalhados. Os grafos por hora mostram os gastos sob demanda com o compromisso recomendado do Savings Plans, fornecendo informações sobre economias estimadas, cobertura do Savings Plans e utilização do Savings Plans. Isso ajuda as organizações a entender como os Savings Plans se aplicam a cada hora de gasto sem precisar investir tempo e recursos na criação de modelos para analisar as despesas. 

 Crie periodicamente relatórios que contêm um destaque de Savings Plans, instâncias reservadas e recomendações de dimensionamento para o Amazon EC2 do AWS Cost Explorer a fim de começar a reduzir o custo associado a workloads estacionárias e recursos ociosos ou subutilizados. Identifique e recupere os gastos associados ao desperdício de recursos implantados na nuvem. O desperdício na nuvem ocorre quando recursos dimensionados incorretamente são criados ou quando se observa padrões de uso diferentes do esperado. Siga as práticas recomendadas da AWS para reduzir o desperdício ou peça ajuda à equipe de contas e parceiro para [otimizar e economizar](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/) os custos da nuvem. 

 Gere relatórios regularmente para melhorar as opções de compra de recursos a fim de reduzir os custos unitários das workloads. Opções de compra como Savings Plans, instâncias reservadas ou instâncias spot do Amazon EC2 oferecem as maiores economias para workloads tolerantes a falhas e permitem que as partes interessadas (proprietários de negócios e equipes financeiras e de tecnologia) façam parte das conversas sobre comprometimento. 

 Compartilhe os relatórios que contêm oportunidades ou anúncios de novos lançamentos que possam ajudar você a reduzir o custo total de propriedade (TCO) da nuvem. Adote novos serviços, regiões, recursos, soluções ou maneiras de obter mais reduções de custo. 

### Etapas para a implementação
<a name="implementation-steps"></a>
+  **Configurar o AWS Budgets:** configure o AWS Budgets em todas as contas para a sua workload. Defina um orçamento para o gasto total da conta e outro para a carga de trabalho usando tags. 
  +  [Laboratórios do Well-Architected: Governança de custo e uso](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  **Relatório sobre otimização de custos:** Configure um ciclo regular para discutir e analisar a eficiência da carga de trabalho. Usando as métricas estabelecidas, informe sobre as métricas obtidas e o custo de alcançá-las. Identifique e corrija tendências negativas, bem como tendências positivas que possam ser promovidas em toda a organização. Os relatórios devem envolver representantes das equipes e proprietários de aplicações, bem como do setor financeiro, e os principais tomadores de decisão sobre as despesas com a nuvem. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 
+  [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 
+  [AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) 
+  [Práticas recomendadas do AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html#budgets-best-practices-setting-budgets%3Fsc_channel=ba%26sc_campaign=aws-budgets%26sc_medium=manage-and-control%26sc_content=web_pdp%26sc_detail=how-do-I%26sc_outcome=aw%26trk=how-do-I_web_pdp_aws-budgets) 
+  [Análises do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html) 

 **Exemplos relacionados:** 
+  [Laboratórios do Well-Architected: Governança de custo e uso](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  [Principais formas de começar a otimizar seus custos de nuvem da AWS](https://aws.amazon.com/blogs/aws-cloud-financial-management/key-ways-to-start-optimizing-your-aws-cloud-costs/) 

# COST01-BP06 Monitore custos proativamente
<a name="cost_cloud_financial_management_proactive_process"></a>

Implemente ferramentas e painéis para monitorar os custos proativamente para a carga de trabalho. Analise regularmente os custos com ferramentas configuradas ou prontas para usar em vez de apenas analisar os custos e as categorias quando receber notificações. O monitoramento e a análise proativa dos custos ajuda a identificar tendências positivas e permite que você as promova em toda a organização. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

é recomendável monitorar custos e uso proativamente em sua organização, e não apenas quando há exceções ou anomalias. Painéis altamente visíveis em todo o escritório ou ambiente de trabalho garantem que as principais pessoas tenham acesso às informações necessárias e indicam o foco da organização na otimização de custos. Os painéis visíveis permitem promover ativamente resultados bem-sucedidos e implementá-los em toda a organização.

Crie uma rotina diária ou frequente de uso do [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) ou de qualquer outro painel, como o [Amazon Quick](https://aws.amazon.com/quicksight/) , para ver os custos e analisar de forma proativa. Analise o uso e os custos dos serviços da AWS na conta da AWS, no nível da workload ou em um serviço específico da AWS com agrupamento e filtragem, e valide se estão dentro do esperado ou não. Use a granularidade no nível de hora e recurso e as tags para filtrar e identificar os custos incorridos para os principais recursos. Você também pode criar seus próprios relatórios com o [painel de inteligência de custos](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/), uma solução do [Amazon Quick](https://aws.amazon.com/quicksight/) desenvolvida por arquitetos de soluções da AWS, e comparar os orçamentos com o uso e os custos reais.

**Etapas da implementação**
+  **Relatório sobre otimização de custos:** Configure um ciclo regular para discutir e analisar a eficiência da carga de trabalho. Usando as métricas estabelecidas, informe sobre as métricas obtidas e o custo de alcançá-las. Identifique e corrija quaisquer tendências negativas e identifique tendências positivas a serem promovidas em toda a organização. Os relatórios devem envolver representantes das equipes de aplicativos e dos proprietários, das finanças e da gerência. 
+ **Crie e habilite a granularidade diária do [AWS Budgets](https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-daily-cost-and-usage-budgets/) para o uso e os custos a fim de tomar medidas oportunas para impedir quaisquer possíveis excessos de custo: ** o AWS Budgets permite que você configure notificações de alerta, para que permaneça informado se qualquer tipo de orçamento sair dos limites pré-configurados. A melhor forma de aproveitar o AWS Budgets é definir o custo e o uso esperados como limites, para que qualquer coisa acima do seu orçamento seja considerada excesso.
+ **Crie AWS Cost Anomaly Detection para o monitor de custos: ** [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) usa tecnologia avançada de machine learning para identificar gastos anormais e causas raiz, para que você possa agir rapidamente. Permite que você configure monitores de custo que definem os segmentos de gastos que deseja avaliar (por exemplo, serviços individuais da AWS, contas de membros, tags de alocação de custo e categorias de custo) e permite que você defina quando, onde e como recebe notificações de alerta. Para cada monitor, anexe várias assinaturas de alertas para proprietários de negócios e equipes de tecnologia, incluindo um nome, um limite de impacto do custo e a frequência de alerta (alertas individuais, resumo diário, resumo semanal) para cada assinatura.
+ **Use o AWS Cost Explorer ou integre seus dados do AWS Cost and Usage Report (CUR) com painéis do Amazon Quick para visualizar os custos da organização:** o AWS Cost Explorer conta com uma interface fácil de usar que permite que você visualize, entenda e gerencie os custos e o uso da AWS com o passar do tempo. O [painel de inteligência de custos](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) é um painel personalizável e acessível para ajudar a criar a base de sua própria ferramenta de gerenciamento e otimização dos custos.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ [Orçamentos diários para custos e uso](https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-daily-cost-and-usage-budgets/)
+ [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)

 **Exemplos relacionados:** 
+  [Laboratórios do Well-Architected: Visualização](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html) 
+  [Laboratórios do Well-Architected: Visualização avançada](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+ [Laboratórios do Well-Architected: Painéis de inteligência de nuvem](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/)
+ [Laboratórios do Well-Architected: Visualização de custos](https://wellarchitectedlabs.com/cost/200_labs/200_5_cost_visualization/)
+ [Alerta do AWS Cost Anomaly Detection com Slack](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/)

# COST01-BP07 Manter-se atualizado com os novos lançamentos de serviços
<a name="cost_cloud_financial_management_scheduled"></a>

 Consulte regularmente especialistas ou parceiros da AWS para considerar quais serviços e recursos oferecem menor custo. Analise os blogs da AWS e outras fontes de informação. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

A AWS adiciona novos recursos constantemente para que você possa aproveitar as tecnologias mais recentes a fim de experimentar e inovar com maior rapidez. Você pode implementar novos serviços e recursos da AWS para aumentar a eficiência de custos na workload. Confira regularmente o [Gerenciamento de custos da AWS](https://aws.amazon.com/aws-cost-management/), o [Blog de novidades da AWS](https://aws.amazon.com/blogs/aws/), o [Blog de gerenciamento de custos da AWS](https://aws.amazon.com/blogs/aws-cloud-financial-management/)e aos [Novidades da AWS](https://aws.amazon.com/new/) para obter informações sobre novos lançamentos de serviços e recursos. As postagens de Novidades oferecem uma breve visão geral de todos os anúncios de serviços, recursos e expansões de regiões da AWS à medida que são lançados.

**Etapas da implementação**
+  **Inscrever-se em blogs:** Acesse as páginas de blogs da AWS e inscreva-se em Novidades e em outros blogs relevantes. Você pode inscrever-se na página de [preferências de comunicação](https://pages.awscloud.com/communication-preferences?languages=english) com seu endereço de e-mail.
+ **Inscrever-se para receber as Novidades da AWS: **Confira regularmente o [Blog de novidades da AWS](https://aws.amazon.com/blogs/aws/) e [Novidades da AWS](https://aws.amazon.com/new/) para obter informações sobre novos lançamentos de serviços e recursos. Assine o feed RSS, ou use seu e-mail para ficar por dentro dos anúncios e lançamentos.
+ **Seguir as reduções de preço da AWS:** cortes regulares nos preços de todos os nossos serviços são uma prática padrão que a AWS usa para passar os benefícios econômicos obtidos pela nossa escala aos clientes. Até abril de 2022, a AWS já reduziu preços 115 vezes desde seu lançamento em 2006. Se você tiver qualquer decisão comercial pendente por motivos de preço, poderá reavaliar depois de reduções de preços e novas integrações de serviços. Você pode saber mais sobre nossos esforços anteriores para redução de preços, incluindo instâncias do Amazon Elastic Compute Cloud (Amazon EC2), na [categoria de redução de preços do Blog de novidades da AWS](https://aws.amazon.com/blogs/aws/category/price-reduction/).
+ ** Eventos e reuniões da AWS: **participe da conferência local da AWS e de qualquer reunião local com outras organizações da área. Se não puder participar presencialmente, tente participar dos eventos virtuais para ouvir mais de especialistas da AWS e casos de negócios de outros clientes.
+ ** Reunir-se com a equipe da sua conta: **programe um ritmo regular com a equipe de contas, encontre-se com ela e discuta as tendências do setor e os serviços da AWS. Fale com o gerente de contas, o arquiteto de soluções e a equipe de suporte. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Gerenciamento de custos da AWS](https://aws.amazon.com/aws-cost-management/) 
+ [Novidades da AWS](https://aws.amazon.com/new/)
+  [Blog de novidades da AWS](https://aws.amazon.com/blogs/aws/) 

 **Exemplos relacionados:** 
+  [Amazon EC2: 15 anos de otimização e economia de custos de TI](https://aws.amazon.com/blogs/aws-cost-management/amazon-ec2-15th-years-of-optimizing-and-saving-your-it-costs/) 
+ [Blog de novidades da AWS: redução de preços](https://aws.amazon.com/blogs/aws/category/price-reduction/)

# COST01-BP08 Criar uma cultura com reconhecimento de custos
<a name="cost_cloud_financial_management_culture"></a>

 Implemente mudanças ou programas em toda a organização para criar uma cultura com reconhecimento de custos. É recomendável começar aos poucos e, à medida que seus recursos aumentarem e o uso da nuvem por sua organização aumentar, implementar programas grandes e abrangentes. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação de implementação
<a name="implementation-guidance"></a>

Uma cultura com reconhecimento de custos permite escalar a otimização de custos e o gerenciamento financeiro na nuvem (operações financeiras, centro de excelência da nuvem, equipes de operações na nuvem e assim por diante) por meio de práticas recomendadas executadas de maneira orgânica e descentralizada em toda a organização. O reconhecimento de custos permite que você crie altos níveis de capacidade em toda a organização com o mínimo de esforço, em comparação com uma abordagem centralizada e de cima para baixo.

Provocar o reconhecimento de custos em computação em nuvem, principalmente para geradores de custos primários na computação em nuvem, permite que as equipes entendam os resultados esperados de quaisquer alterações na perspectiva de custo. As equipes que acessam os ambientes de nuvem devem conhecer os modelos de preços e a diferença entre datacenters on-premises tradicionais e computação em nuvem.

O principal benefício de uma cultura com reconhecimento de custos é que as equipes de tecnologia otimizam os custos de maneira proativa e contínua (por exemplo, são consideradas um requisito não funcional ao arquitetar novas workloads ou alterar workloads existentes) em vez de realizarem otimizações de custo reativas somente quando necessárias.

Pequenas mudanças na cultura podem ter grandes impactos na eficiência de suas cargas de trabalho atuais e futuras. Exemplos disso incluem:
+ Oferecer visibilidade e conscientizar as equipes de engenharia para que entendam o que fazem e qual seu impacto em termos de custo.
+ Gamificação do custo e do uso em toda a organização. Isso pode ser feito por meio de um painel visível publicamente ou de um relatório que compara custos e uso normalizados entre equipes (por exemplo, custo por workload e custo por transação).
+ Reconhecimento da eficiência de custos. Recompense realizações de otimização de custos voluntárias ou não solicitadas publicamente ou de forma privada e aprenda com os erros para evitar repeti-los no futuro.
+ Criar requisitos organizacionais de cima para baixo para workloads a serem executadas em orçamentos predefinidos.
+ Questionar os requisitos comerciais das mudanças e o impacto sobre os custos das mudanças solicitadas na infraestrutura de arquitetura ou configuração de workload para garantir que você pague somente o necessário.
+ Garantir que o planejador de mudanças esteja ciente das mudanças esperadas que impactam o custo, e que sejam confirmadas pelas partes interessadas para que proporcionem resultados comerciais com economia.

**Etapas da implementação**
+ **Informar os custos de nuvem às equipes de tecnologia:** para conscientizar sobre os custos e estabelecer KPIs de eficiência para partes interessadas financeiras e comerciais.
+ **Informar partes interessadas ou membros da equipe sobre mudanças planejadas:** Crie um item na agenda para discutir mudanças planejadas e o impacto de custo-benefício sobre a workload durante as reuniões semanais de mudanças.
+ ** Reunir-se com a equipe da sua conta: **Estabelecer reuniões regulares com a equipe de contas e discutir as tendências do setor e os serviços da AWS. Fale com o gerente de contas, o arquiteto e a equipe de suporte. 
+ **Compartilhe histórias de sucesso:** compartilhe histórias de sucesso sobre redução de custo de qualquer workload, Conta da AWS ou organização para gerar uma atitude positiva e encorajar sobre a otimização dos custos.
+ **Treinamento: **garanta que as equipes técnicas ou os membros da equipe sejam treinados reconhecer os custos dos recursos na Nuvem AWS.
+ ** Eventos e reuniões da AWS: **participe das conferências locais da AWS e de qualquer reunião local com outras organizações da área. 
+  **Inscrever-se em blogs:** acesse as páginas do Blog da AWS e inscreva-se no [Blog de novidades](https://aws.amazon.com/new/) e outros blogs relevantes para ficar por dentro dos novos lançamentos, implementações, exemplos e mudanças compartilhados pela AWS. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Blog da AWS](https://aws.amazon.com/blogs/) 
+  [Gerenciamento de custos da AWS](https://aws.amazon.com/blogs/aws-cost-management/) 
+  [Blog de novidades da AWS](https://aws.amazon.com/blogs/aws/) 

 **Exemplos relacionados:** 
+  [Gerenciamento financeiro na nuvem da AWS](https://aws.amazon.com/blogs/aws-cloud-financial-management/) 
+  [AWS Well-Architected Labs: gerenciamento financeiro na nuvem](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/1_cloud_financial_management/) 

# COST01-BP09 Quantificar o valor comercial proveniente da otimização de custos
<a name="cost_cloud_financial_management_quantify_value"></a>

 A quantificação do valor empresarial da otimização de custos permite que você entenda todo o conjunto de benefícios da sua organização. Como a otimização de custos é um investimento necessário, quantificar o valor empresarial permite que você explique o retorno sobre o investimento para as partes interessadas. A quantificação do valor empresarial pode ajudá-lo a ganhar mais participação das partes interessadas em futuros investimentos de otimização de custos e fornece uma estrutura para medir os resultados das atividades de otimização de custos da sua organização. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Quantificar o valor comercial significa avaliar os benefícios que as empresas obtêm com as ações e decisões que tomam. O valor comercial pode ser tangível (como a redução das despesas ou o aumento dos lucros) ou intangível (como a melhoria da reputação da marca ou o aumento da satisfação do cliente). 

 Quantificar o valor comercial proveniente da otimização de custos significa determinar o valor ou o benefício que você está obtendo de seus esforços para gastar com maior eficiência. Por exemplo, se uma empresa gastar USD 100 mil para implantar uma workload na AWS e depois otimizá-la, o novo custo se tornará apenas USD 80 mil, sem prejudicar a qualidade ou a produção. Nesse cenário, o valor comercial quantificado da otimização de custos seria uma economia de USD 20 mil. Mas, além das economias, a empresa também pode quantificar o valor em termos de prazos de entrega mais rápidos, maior satisfação do cliente ou outras métricas resultantes das iniciativas de otimização de custos. As partes interessadas precisam tomar decisões sobre o valor em potencial da otimização de custos, o custo da otimização da workload e o valor de retorno. 

 Além de relatar economias com base na otimização de custos, é recomendável quantificar o valor adicional entregue. Os benefícios de otimização de custos normalmente são quantificados em termos de custos mais baixos por resultado comercial. Por exemplo, é possível quantificar a redução de custo do Amazon Elastic Compute Cloud (Amazon EC2) ao comprar Savings Plans, que reduzem os custos e mantêm os níveis de saída da workload. É possível quantificar a redução de custos em relação aos gastos na AWS quando instâncias ociosas do Amazon EC2 são removidas ou quando volumes não anexados do Amazon Elastic Block Store (Amazon EBS) são excluídos. 

 No entanto, os benefícios da otimização de custos vão além da redução ou da prevenção de custos. Considere a captura de dados adicionais para medir melhorias de eficiência e valor empresarial. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Avaliar os benefícios dos negócios: **trata-se do processo de analisar e ajustar os custos da Nuvem AWS de forma a maximizar o benefício recebido de cada dólar gasto. Em vez de enfatizar a redução de custos sem valor comercial, considere os benefícios empresarias e o retorno sobre o investimento da otimização de custos, o que pode agregar maior valor ao dispêndio. Isso significa gastar com sabedoria e fazer investimentos e despesas em áreas que geram o melhor retorno. 
+  **Analisar os custos de previsão da AWS:** a previsão ajuda as partes interessadas de finanças a definir expectativas com outras partes interessadas internas e externas da organização, além de ajudar a melhorar a previsibilidade financeira da organização. O [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) pode ser usado para calcular o custo e o uso. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [Nuvem AWS Economics ](https://aws.amazon.com/economics/)
+  [Blog da AWS](https://aws.amazon.com/blogs/) 
+  [Gerenciamento de Custos da AWS](https://aws.amazon.com/blogs/aws-cost-management/) 
+  [ Blog de novidades da AWS](https://aws.amazon.com/blogs/aws/) 
+  [whitepaper sobre o Pilar Confiabilidade do Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) 
+  [Explorador de Custos da AWS](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 

 **Vídeos relacionados:** 
+ [ Desbloquear o valor comercial com o Windows na AWS](https://aws.amazon.com/windows/tco/)

 **Exemplos relacionados:** 
+ [ Medir e maximizar o valor comercial do Customer 360 ](https://pages.awscloud.com/measuring-and-maximizing-the-business-value-of-customer-360-062022.html)
+ [ The Business Value of Adopting Amazon Web Services Managed Databases ](https://pages.awscloud.com/rs/112-TZM-766/images/The Business Value of Adopting Amazon Web Services Managed Databases.pdf)
+ [ The Business Value of Amazon Web Services for Independent Software Vendors ](https://pages.awscloud.com/rs/112-TZM-766/images/The Business Value of Amazon Web Services %28AWS%29 for Independent Software Vendors %28ISVs%29.pdf)
+ [ Business Value of Cloud Modernization ](https://pages.awscloud.com/aws-cfm-known-business-value-of-cloud-modernization-2022.html)
+ [ The Business Value of Migration to Amazon Web Services ](https://pages.awscloud.com/global-in-gc-500-business-value-of-migration-whitepaper-learn.html)

# Reconhecimento de despesas e usos
<a name="a-expenditure-and-usage-awareness"></a>

**Topics**
+ [CUSTOS 2. Como governar o uso?](cost-02.md)
+ [CUSTOS 3. Como monitorar custos e uso?](cost-03.md)
+ [CUSTOS 4. Como desativar os recursos?](cost-04.md)

# CUSTOS 2. Como governar o uso?
<a name="cost-02"></a>

Estabeleça políticas e mecanismos para garantir que os custos adequados sejam gerados enquanto os objetivos são alcançados. Ao empregar uma abordagem de verificação e equilíbrio, você pode inovar sem gastar demais. 

**Topics**
+ [COST02-BP01 Desenvolver políticas com base nos requisitos da sua organização](cost_govern_usage_policies.md)
+ [COST02-BP02 Implementar objetivos e metas](cost_govern_usage_goal_target.md)
+ [COST02-BP03 Implementar uma estrutura de contas](cost_govern_usage_account_structure.md)
+ [COST02-BP04 Implementar grupos e perfis](cost_govern_usage_groups_roles.md)
+ [COST02-BP05 Implementar controles de custos](cost_govern_usage_controls.md)
+ [COST02-BP06 Acompanhar o ciclo de vida do projeto](cost_govern_usage_track_lifecycle.md)

# COST02-BP01 Desenvolver políticas com base nos requisitos da sua organização
<a name="cost_govern_usage_policies"></a>

Desenvolva políticas que definam como os recursos são gerenciados pela sua organização e os inspecione periodicamente. As políticas devem abranger aspectos de custos de recursos e workloads, incluindo criação, modificação e desativação ao longo da vida útil do recurso.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

Entender os custos e os motivadores da sua organização é essencial para gerenciar seus custos e utilização com eficácia e também identificar oportunidades de redução de custos. Normalmente, as organizações operam várias cargas de trabalho executadas por várias equipes. Essas equipes podem estar em diferentes unidades da de negócio organização, cada uma com o próprio fluxo de receita. A capacidade de atribuir os custos dos recursos a cargas de trabalho, à uma organização em particular ou aos donos do produto propicia um comportamento eficiente de uso e ajuda a reduzir o desperdício. O monitoramento preciso de custos e uso ajuda você a entender a otimização de sua workload, bem como a lucratividade das unidades e produtos da organização. Esse conhecimento permite uma tomada de decisão mais consciente sobre onde alocar recursos em sua organização. A conscientização sobre o uso em todos os níveis da organização é essencial para promover mudanças, pois a mudança no uso gera mudanças no custo. Considere adotar uma abordagem multifacetada para manter ciente do seu custo e utilização.

O primeiro passo para realizar governança é usar os requisitos da sua organização para desenvolver políticas para o uso da nuvem. Essas políticas definem como a sua organização usa a nuvem e como os recursos são gerenciados. As políticas devem abranger todos os aspectos de recursos e workloads relacionados ao custo ou à utilização, incluindo criação, modificação e desativação durante a vida útil do recurso. Verifique se as políticas e procedimentos são seguidos e implementados para qualquer alteração em um ambiente de nuvem. Durante as reuniões de gestão de mudanças de TI, questione para descobrir o impacto do custo das alterações planejadas, sejam de aumento ou diminuição, a justificativa de negócios e o resultado esperado. 

As políticas devem ser simples, para que sejam facilmente compreendidas e possam ser implementadas com eficácia em toda a organização. As políticas também precisam ser fáceis de seguir e interpretar (para que sejam usadas) e específicas (para evitar erros de interpretação entre as equipes). Além disso, elas precisam ser inspecionadas periodicamente (como nossos mecanismos) e atualizadas à medida que as condições ou as prioridades de negócios dos clientes mudam, o que tornaria a política desatualizada.

 Comece com políticas amplas e de alto nível, como qual região geográfica usar ou horários do dia em que os recursos devem estar em execução. Refine gradualmente as políticas para as várias unidades organizacionais e cargas de trabalho. As políticas comuns incluem quais serviços e recursos podem ser usados (por exemplo, armazenamento de dados com menor performance em ambientes de teste e desenvolvimento), quais tipos de recursos podem ser usados por diferentes grupos (por exemplo, o maior tamanho de um recurso em uma conta de desenvolvimento é médio) e por quanto tempo esses recursos ficarão em uso (se temporariamente, em curto prazo ou por um período específico). 

 **Exemplo de política** 

 Veja a seguir um exemplo de política que você pode revisar para criar suas próprias políticas de governança de nuvem, que enfocam a otimização de custos. Ajuste a política com base nos requisitos de sua organização e nas solicitações das partes interessadas. 
+  **Nome da política:** Defina um nome de política claro, como Política de otimização de recursos e redução de custos. 
+  **Finalidade:** Explique por que essa política deve ser usada e qual é o resultado esperado. O objetivo dessa política é verificar se há um custo mínimo necessário para implantar e executar a workload desejada para atender aos requisitos de negócios. 
+  **Escopo:** Defina claramente quem deve usar essa política e quando ela deve ser usada, como o DevOps X Team, para usar essa política em clientes do leste dos EUA para o ambiente X (produção ou não produção). 

 **Declaração de política** 

1.  Selecione us-east-1 ou várias regiões do leste dos EUA com base no ambiente de sua workload e nos requisitos de negócios (desenvolvimento, teste de aceitação do usuário, pré-produção ou produção). 

1.  Programe instâncias do Amazon EC2 e do Amazon RDS para execução entre 6h e 20h (Horário Padrão do Leste (EST)). 

1.  Interrompa todas as instâncias do Amazon EC2 não utilizadas após oito horas e as instâncias do Amazon RDS não utilizadas após 24 horas de inatividade. 

1.  Encerre todas as instâncias do Amazon EC2 não utilizadas após 24 horas de inatividade em ambientes que não sejam de produção. Lembre o proprietário da instância do Amazon EC2 (com base em tags) de revisar suas instâncias do Amazon EC2 interrompidas em produção e informá-lo de que suas instâncias do Amazon EC2 serão encerradas em 72 horas se não estiverem em uso. 

1.  Use família de instância e tamanho genéricos, como m5.large, e, depois, redimensione a instância com base na utilização da CPU e da memória usando o AWS Compute Optimizer. 

1.  Priorize o uso do ajuste de escala automático para ajustar dinamicamente o número de instâncias em execução com base no tráfego. 

1.  Use instâncias spot para workloads não essenciais. 

1.  Analise os requisitos de capacidade para comprometer Saving Plans ou instâncias reservadas para workloads previsíveis e informe a equipe de gerenciamento financeiro da nuvem. 

1.  Use políticas de ciclo de vida do Amazon S3 para mover dados acessados com pouca frequência para níveis de armazenamento mais baratos. Se nenhuma política de retenção for definida, use o Amazon S3 Intelligent Tiering para mover objetos automaticamente para a camada arquivada. 

1.  Monitore a utilização de recursos e defina alarmes para acionar eventos de escalabilidade usando o Amazon CloudWatch. 

1.  Para cada Conta da AWS, use o AWS Budgets para definir orçamentos de custo e uso para sua conta com base no centro de custos e nas unidades de negócios. 

1.  Usar o AWS Budgets para definir orçamentos de custo e uso para sua conta pode ajudar você a controlar seus gastos e evitar contas inesperadas, permitindo controlar melhor seus custos. 

 **Procedimento:** Forneça procedimentos detalhados para implementar essa política ou consulte outros documentos que descrevam como implementar cada declaração de política. Esta seção deve fornecer instruções detalhadas para a elaboração dos requisitos da política. 

 Para implementar essa política, você pode usar várias ferramentas de terceiros ou regras do AWS Config para conferir a conformidade com a declaração de política e acionar ações de correção automatizadas usando funções do AWS Lambda. Você também pode usar o AWS Organizations para aplicar a política. Além disso, você deve revisar regularmente o uso de recursos e ajustar a política conforme necessário para verificar se ela continua atendendo às suas necessidades comerciais. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  **Reúna-se com as partes interessadas:** Para desenvolver políticas, peça às partes interessadas (escritórios de negócios na nuvem, engenheiros ou tomadores de decisão funcionais para aplicação de políticas) em sua organização que especifiquem seus requisitos e os documentem. Adote uma abordagem ampla e iterativa iniciando em alto nível com um refinamento contínuo até os mínimos detalhes em cada etapa. Os membros da equipe incluem aqueles com interesse direto na workload, como unidades da organização ou proprietários de aplicativos, bem como grupos de apoio, como equipes de segurança e finanças.
+  **Obtenha confirmação:** garanta que as equipes concordem com as políticas de quem pode acessar e implantar na Nuvem AWS. Certifique-se de que elas sigam as políticas da sua organização e confirme se o provisionamento de recursos está alinhado com as políticas e procedimentos estabelecidos. 
+  **Crie sessões de treinamento de integração:** peça que os novos membros completem cursos de formação de integração para criar conscientização de custo e requisitos da organização. As equipes podem assumir diferentes políticas das suas experiências anteriores ou nem pensar nelas. 
+ ** Defina locais para sua workload: **Defina onde sua carga de trabalho opera, incluindo o país e a área dentro do país. Essas informações são usadas para mapear as zonas de disponibilidade e Regiões da AWS. 
+ ** Defina e agrupe serviços e recursos: **Defina os serviços que as cargas de trabalho exigem. Para cada serviço, especifique os tipos, o tamanho e o número de recursos necessários. Defina grupos para os recursos por função, como servidores de aplicativos ou armazenamento de banco de dados. Os recursos podem pertencer a vários grupos. 
+  **Defina e agrupe os usuários por função: **Defina os usuários que interagem com a carga de trabalho, concentrando-se no que eles fazem e em como usam a carga de trabalho, não em quem são ou na posição deles na organização. Agrupe usuários ou funções semelhantes. Você pode usar as políticas gerenciadas da AWS como um guia. 
+ ** Defina as ações:** Usando os locais, recursos e usuários identificados anteriormente, defina as ações que são exigidas por cada um para alcançar os resultados da carga de trabalho ao longo do tempo de vida (desenvolvimento, operação e desativação). Identifique as ações com base nos grupos, e não nos elementos individuais nos grupos, em cada local. Comece amplamente como leitura ou gravação e, em seguida, refine ações específicas para cada serviço. 
+ ** Defina o período de análise:** As cargas de trabalho e os requisitos organizacionais podem mudar ao longo do tempo. Defina a programação de análise da workload para garantir que permaneça alinhada com as prioridades da organização. 
+  **Documente as políticas: **Verifique se as políticas que foram definidas estão acessíveis conforme exigido pela sua organização. Essas políticas são usadas para implementar, manter e auditar o acesso de seus ambientes. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Gerenciamento de alterações na nuvem](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-cloud.html) 
+  [Políticas gerenciadas pela AWS para funções de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [Estratégia de faturamento de várias contas da AWS](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [Ações, recursos e chaves de condição para serviços da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html) 
+  [Gerenciamento e governança da AWS](https://aws.amazon.com/products/management-and-governance/) 
+  [Controlar o acesso às Regiões da AWS usando as políticas do IAM](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [Regiões e AZs de infraestruturas globais](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 

 **Vídeos relacionados:** 
+  [AWS Management and Governance at Scale (Gerenciamento e governança da AWS em grande escala)](https://www.youtube.com/watch?v=xdJSUnPcPPI) 

 **Exemplos relacionados:** 
+  [VMware: o que são políticas de nuvem?](https://blogs.vmware.com/cloudhealth/what-are-cloud-policies/) 

# COST02-BP02 Implementar objetivos e metas
<a name="cost_govern_usage_goal_target"></a>

Implemente objetivos e metas de custo e uso para sua workload. Os objetivos fornecem orientação para sua organização quanto aos resultados esperados, e as metas oferecem resultados mensuráveis específicos a serem alcançados para suas workloads.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

Desenvolva objetivos e metas de custo e uso para a sua organização. Como uma organização em crescimento na AWS, é importante definir e monitorar objetivos para otimização de custos. Esses objetivos ou [indicadores-chave de desempenho (KPIs)](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metric-the-touchstone-of-your-it-planning-and-evaluation/) podem incluir itens como porcentagem de gastos sob demanda ou adoção de certos serviços otimizados, como instâncias do AWS Graviton ou tipos de volume gp3 do EBS. Definir objetivos mensuráveis e viáveis pode ajudar você a continuar a medir as melhorias de eficiência, o que é importante para as operações comerciais em andamento. Os objetivos fornecem orientações e direcionamento para a sua organização sobre os resultados esperados. As metas fornecem resultados mensuráveis específicos a serem alcançados. Em suma, um objetivo é a direção que você deseja seguir e a meta é até que ponto nessa direção o objetivo deve ir e quando ele deve ser concretizado (usando a orientação de específico, mensurável, atribuível, realista e oportuno, ou SMART). Um exemplo de objetivo é que o uso da plataforma deve aumentar significativamente, com apenas um pequeno aumento (não linear) no custo. Um exemplo de meta é um aumento de 20% no uso da plataforma, com um aumento de menos de 5% nos custos. Outro objetivo comum é que as workloads precisam ser mais eficientes a cada seis meses. A meta complementar seria o custo de acordo com as métricas empresariais diminuir em 5% a cada seis meses. 

Uma meta para a otimização de custos é aumentar a eficiência da workload, o que significa diminuir o custo por resultado empresarial da workload ao longo do tempo. É recomendável implementar esse objetivo para todas as workloads e também definir uma meta, como um aumento de 5% na eficiência a cada seis meses a um ano. Isso pode ser obtido na nuvem por meio da criação de recursos na otimização de custos e do lançamento de serviços e recursos.

 É importante ter visibilidade quase em tempo real sobre seus KPIs e oportunidades de economia relacionadas e acompanhar seu progresso ao longo do tempo. Para começar a definir e monitorar os objetivos de KPI, recomendamos o painel de KPI da [framework de Painéis de inteligência em nuvem (CID)](https://aws.amazon.com/blogs/mt/visualize-and-gain-insights-into-your-aws-cost-and-usage-with-cloud-intelligence-dashboards-using-amazon-quicksight/). Com base nos dados do AWS Cost and Usage Report, o painel de KPI oferece uma série de KPIs de otimização de custos recomendados com a capacidade de definir objetivos personalizados e acompanhar o progresso ao longo do tempo. 

 Se você tiver outra solução que possibilite definir e monitorar objetivos de KPI, garanta que ela seja adotada por todos as partes interessadas de gerenciamento financeiro em nuvem em sua organização. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  **Definir níveis de uso esperados: **Para começar, enfoque os níveis de uso. Interaja com os proprietários de aplicativos, marketing e equipes de negócios maiores para entender quais serão os níveis de uso esperados para a workload. Como a demanda do cliente mudará ao longo do tempo, e haverá alterações devido a aumentos sazonais ou campanhas de marketing? 
+ ** Definir custos e recursos de workload: **Com os níveis de uso definidos, quantifique as alterações nos recursos da workload necessárias para atender a esses níveis de uso. Pode ser necessário aumentar o tamanho ou o número de recursos para um componente de workload, aumentar a transferência de dados ou alterar componentes de workload para um serviço diferente em um nível específico. Especifique quais serão os custos em cada um desses pontos principais e quais serão as alterações no custo quando houver alterações no uso. 
+  **Definir objetivos empresariais: **Combine o resultado das alterações esperadas no uso e no custo com as alterações esperadas na tecnologia ou qualquer programa que você esteja executando e desenvolva metas para a carga de trabalho. Os objetivos devem abordar o uso, o custo e a relação entre os dois. Os objetivos devem ser simples, de alto nível e ajudar as pessoas a entenderem o que o negócio espera em termos de resultados (como garantir que recursos não utilizados sejam mantidos abaixo de determinado nível de custo). Não é necessário definir objetivos para cada tipo de recurso não utilizado ou definir custos que causem perdas para objetivos e metas. Verifique se há programas organizacionais (por exemplo, criação de recursos como treinamento e educação) se houver alterações esperadas no custo sem alterações no uso.
+  **Definir metas: **Para cada uma das metas definidas, especifique um objetivo mensurável. Se o objetivo for aumentar a eficiência na workload, a meta quantificará a melhoria (típica nos resultados de negócios para cada dólar gasto) e quando ela será entregue. Por exemplo, se você define um objetivo de minimizar o desperdício causado pelo superprovisionamento, sua meta pode ser que o desperdício decorrente do superprovisionamento de computação no primeiro nível de workloads de produção não exceda 10% do custo de computação do nível e que o desperdício devido ao superprovisionamento de computação no segundo nível de workloads de produção não exceda 5% do custo de computação do nível. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Políticas gerenciadas pela AWS para funções de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [Estratégia de várias contas da AWS para sua zona de pouso do AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) 
+  [Controlar o acesso às Regiões da AWS usando as políticas do IAM](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+ [ Objetivos do SMART ](https://en.wikipedia.org/wiki/SMART_criteria)

 **Vídeos relacionados:** 
+ [ Laboratórios do Well-Architected: Objetivos e metas (nível 100) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/)

 **Exemplos relacionados:** 
+ [ Laboratórios do Well-Architected: Recursos de desativação (objetivos e metas) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/)
+ [ Laboratórios do Well-Architected: Tipo, tamanho e número do recurso (objetivos e metas) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/6_resource_type_size_number/)

# COST02-BP03 Implementar uma estrutura de contas
<a name="cost_govern_usage_account_structure"></a>

 Implemente uma estrutura de contas que mapeie para sua organização. Isso auxilia na alocação e no gerenciamento de custos em toda a organização. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 O AWS Organizations permite criar várias Contas da AWS que podem ajudar você a gerenciar de maneira centralizada seu ambiente à medida que dimensiona suas workloads na AWS. É possível modelar sua hierarquia organizacional agrupando Contas da AWS na estrutura da unidade organizacional (UO) e criando várias Contas da AWS em cada UO. Para criar uma estrutura de contas, primeiramente, você precisa decidir qual das suas Contas da AWS será a conta de gerenciamento. Depois disso, você pode criar Contas da AWS ou selecionar contas existentes como contas membro com base na estrutura de contas projetada seguindo as [práticas recomendadas de conta de gerenciamento](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html) e as [práticas recomendadas de conta membro](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html). 

 Recomenda-se que sempre haja, pelo menos, uma conta de gerenciamento com uma conta membro, independentemente do tamanho ou uso da organização. Todos os recursos de workload devem residir somente nas contas membro e nenhum recurso deve ser criado na conta de gerenciamento. Não há uma resposta geral para a quantidade de Contas da AWS que você deve ter. Avalie seus modelos de custo e operacionais atuais e futuros para garantir que a estrutura de suas Contas da AWS reflita os objetivos da sua organização. Algumas empresas criam várias Contas da AWS por motivos de negócios, por exemplo: 
+ O isolamento administrativo ou fiscal e de faturamento é necessário entre unidades da organização, centros de custo ou workloads específicas.
+ Os limites de serviço da AWS são definidos para que sejam específicos a determinadas workloads.
+ Há um requisito de isolamento e separação entre workloads e recursos.

 Dentro do [AWS Organizations](https://aws.amazon.com/organizations/), o [faturamento consolidado](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) cria a estrutura entre uma ou mais contas membro e a conta de gerenciamento. As contas membro permitem que você isole e diferencie seu custo e uso por grupos. Uma prática comum é ter contas membro separadas para cada unidade da organização (como finanças, marketing e vendas), ou para cada ciclo de vida do ambiente (como desenvolvimento, teste e produção) ou para cada workload (workload a, b e c) e, em seguida, agregar essas contas vinculadas usando o faturamento consolidado. 

 O faturamento consolidado permite consolidar o pagamento de várias Contas da AWS membro em uma única conta de gerenciamento, sem deixar de oferecer visibilidade para a atividade de cada conta vinculada. Como os custos e o uso são agregados na conta de gerenciamento, você pode maximizar seus descontos por volume de serviço e maximizar o uso de seus descontos de compromisso (Savings Plans e instâncias reservadas) para obter os descontos mais altos. 

 O diagrama a seguir mostra como você pode usar o AWS Organizations com unidades organizacionais (UO) para agrupar várias contas e colocar várias Contas da AWS em cada UO. Recomenda-se usar UOs para vários casos de uso e workloads que fornecem padrões para organizar contas. 

![\[Tree diagram showing how to group multiple accounts under organizational units.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/aws-organizations-ou-grouping.png)


 [AWS Control Tower](https://aws.amazon.com/controltower/) pode instalar e configurar rapidamente várias contas da AWS, garantindo que a governança esteja alinhada com os requisitos da organização.

**Etapas da implementação** 
+  **Definir requisitos de separação: **os requisitos de separação são uma combinação de vários fatores, que incluem estruturas de segurança, de confiabilidade e financeiras. Trabalhe em cada fator em ordem e especifique se a workload ou o ambiente dela deve ser separado de outras workloads. A segurança promove a adesão aos requisitos de acesso e de dados. A confiabilidade gerencia os limites para que os ambientes e as workloads não afetem os outros. Revise os pilares de segurança e de confiabilidade do Well-Architected Framework periodicamente e siga as práticas recomendadas fornecidas. As estruturas financeiras criam separação financeira rígida (diferentes centros de custo, propriedades de workload e responsabilidades). Exemplos comuns de separação são workloads de produção e de teste executadas em contas separadas ou o uso de uma conta separada para que os dados da fatura e do faturamento possam ser fornecidos às unidades de negócios individuais ou aos departamentos da organização, ou à parte interessada que possui a conta. 
+  **Definir requisitos de agrupamento:** os requisitos de agrupamento não substituem os requisitos de separação, mas são usados para auxiliar no gerenciamento. Agrupe ambientes semelhantes ou workloads que não exigem separação. Um exemplo disso é o agrupamento de vários ambientes de teste ou desenvolvimento de uma ou mais workloads.
+  **Definir a estrutura de contas: **Usando essas separações e agrupamentos, especifique uma conta para cada grupo e mantenha os requisitos de separação. Essas contas são suas contas membro ou vinculadas. Ao agrupar essas contas membro em uma única conta de gerenciamento ou pagante, você combina o uso, o que permite maiores descontos por volume em todas as contas e fornece uma única fatura para todas as contas. É possível separar dados de faturamento e fornecer a cada conta membro uma visualização individual dos dados de faturamento. Se uma conta membro não precisar ter os dados de uso ou de faturamento visíveis para nenhuma outra conta, ou se uma fatura separada da AWS for necessária, você deverá definir várias contas de gerenciamento ou pagantes. Nesse caso, cada conta membro tem a própria conta de gerenciamento ou pagante. Os recursos devem sempre ser colocados em contas membro ou vinculadas. As contas de gerenciamento ou pagantes devem ser usadas somente para gerenciamento. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Uso de tags de alocação de custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) 
+  [Políticas gerenciadas da AWS para funções de trabalho](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html) 
+  [Estratégia de faturamento de várias contas da AWS](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [Controle o acesso a Regiões da AWS usando as políticas do IAM](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [AWS Control Tower](https://aws.amazon.com/controltower/) 
+  [AWS Organizations](https://aws.amazon.com/organizations/) 
+  Práticas recomendadas para [contas de gerenciamento](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html) e [contas membro](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html) 
+  [Organização do ambiente usando várias contas da AWS](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 
+  [Ativação de instâncias reservadas compartilhadas e descontos de Savings Plans](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html) 
+  [Faturamento consolidado](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) 
+  [Faturamento consolidado](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) 

 **Exemplos relacionados:** 
+  [Divisão do CUR e compartilhamento do acesso](https://wellarchitectedlabs.com/Cost/Cost_and_Usage_Analysis/300_Splitting_Sharing_CUR_Access/README.html) 

 **Vídeos relacionados:** 
+ [Apresentação do AWS Organizations](https://www.youtube.com/watch?v=T4NK8fv8YdI)
+ [ Configuração de um ambiente de várias contas da AWS que usa as práticas recomendadas para AWS Organizations](https://www.youtube.com/watch?v=uOrq8ZUuaAQ)

 **Exemplos relacionados:** 
+ [ Laboratórios do Well-Architected: criação de uma organização da AWS (Nível 100) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_1_aws_account_setup/2_account_structure/)
+ [ Divisão do AWS Cost and Usage Report e compartilhamento do acesso ](https://wellarchitectedlabs.com/cost/300_labs/300_splitting_sharing_cur_access/)
+  [Definição de uma estratégia de várias contas da AWS para empresas de telecomunicações](https://aws.amazon.com/blogs/industries/defining-an-aws-multi-account-strategy-for-telecommunications-companies/) 
+  [Práticas recomendadas para otimização das Contas da AWS](https://aws.amazon.com/blogs/architecture/new-whitepaper-provides-best-practices-for-optimizing-aws-accounts/) 
+  [Práticas recomendadas para unidades organizacionais com o AWS Organizations](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/?org_product_gs_bp_OUBlog) 

# COST02-BP04 Implementar grupos e perfis
<a name="cost_govern_usage_groups_roles"></a>

 Implemente grupos e funções que se alinhem com as políticas e controle quem pode criar, modificar ou desativar instâncias e recursos em cada grupo. Por exemplo, implemente grupos de desenvolvimento, teste e produção. Isso se aplica a serviços da AWS e a soluções de terceiros. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

Os perfis e os grupos de usuários são elementos fundamentais no design e na implementação de sistemas seguros e eficientes. Os perfis e os grupos ajudam as organizações a equilibrar a necessidade de controle com a necessidade de flexibilidade e produtividade, e, acima de tudo, apoiando os objetivos organizacionais e as necessidades dos usuários. Conforme recomendado na seção [Gerenciamento de identidade e acesso](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) do Pilar Segurança: AWS Well-Architected Framework, você precisa ter permissões e gerenciamento de identidade robustos para fornecer acesso aos recursos certos para as pessoas certas nas condições certas. Os usuários recebem somente o acesso necessário para realizar suas tarefas. Isso minimiza o risco associado ao acesso não autorizado ou ao uso indevido.

 Depois de desenvolver políticas, é possível criar perfis e grupos lógicos de usuários em sua organização. Isso permite que você atribua permissões, controle o uso e ajude a implementar mecanismos robustos de controle de acesso, impedindo o acesso não autorizado a informações sigilosas. Comece com agrupamentos de pessoas de alto nível. Normalmente isso se alinha com as unidades organizacionais e os cargos (por exemplo, administrador de sistemas no departamento de TI, controlador financeiro ou analista de negócios). Os grupos categorizam pessoas que realizam tarefas semelhantes e precisam de acesso semelhante. As funções definem o que um grupo deve fazer. É mais fácil gerenciar permissões para grupos e perfis do que para usuários individuais. Os perfis e os grupos atribuem permissões de forma consistente e sistemática a todos os usuários, evitando erros e inconsistências. 

 Quando o perfil de um usuário muda, os administradores podem ajustar o acesso por perfil ou grupo, em vez de reconfigurar as contas de usuários individuais. Por exemplo, um administrador de sistemas em TI requer acesso para criar todos os recursos, mas um membro da equipe de análise só precisa criar recursos de análise. 

### Etapas da implementação
<a name="implementation-steps"></a>
+ ** Implementar grupos: **usando os grupos de usuários definidos em suas políticas organizacionais, implemente os grupos correspondentes, se necessário. Para obter as práticas recomendadas sobre usuários, grupos e autenticação, consulte o [Pilar Segurança:](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) AWS Well-Architected Framework.
+ ** Implementar perfis e políticas: **usando as ações definidas nas políticas organizacionais, crie os perfis e as políticas de acesso necessárias. Para obter as práticas recomendadas sobre perfis e políticas, consulte o [Pilar Segurança:](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) AWS Well-Architected Framework.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Políticas gerenciadas da AWS para funções de trabalho](https://docs.aws.amazon.com/iam/latest/UserGuide/access_policies_job-functions.html) 
+  [Estratégia de faturamento de várias contas da AWS](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [Pilar Segurança: AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) 
+ [AWS Identity and Access Management (IAM) ](https://aws.amazon.com/iam/)
+ [ Políticas do AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)

 **Vídeos relacionados:** 
+ [ Why use Identity and Access Management ](https://www.youtube.com/watch?v=SXSqhTn2DuE)

 **Exemplos relacionados:** 
+  [Laboratório do Well-Architected: Identidade e acesso básico](https://wellarchitectedlabs.com/Security/100_Basic_Identity_and_Access_Management_User_Group_Role/README.html) 
+  [Control access to Regiões da AWS using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+ [ Starting your Cloud Financial Management journey: Cloud cost operations ](https://aws.amazon.com/blogs/aws-cloud-financial-management/op-starting-your-cloud-financial-management-journey/)

# COST02-BP05 Implementar controles de custos
<a name="cost_govern_usage_controls"></a>

 Implemente controles baseados nas políticas da organização e nas funções e grupos definidos. Isso garante que os custos sejam gerados somente conforme definido pelos requisitos da organização, como controle do acesso a regiões ou tipos de recursos. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

Uma primeira etapa comum na implementação de controles de custo é configurar notificações quando eventos de custo ou de uso ocorrerem fora das políticas. É possível tomar medidas rápidas e verificar se é necessária uma ação corretiva, sem restringir ou afetar negativamente workloads ou novas atividades. Depois de conhecer os limites de workload e do ambiente, você pode aplicar a governança. O [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) permite que você defina notificações e orçamentos mensais para custos, uso e descontos de compromisso da conta da AWS (Savings Plans e instâncias reservadas). Você pode criar orçamentos em um nível de custo agregado (por exemplo, todos os custos) ou em um nível mais granular, onde você inclui apenas dimensões específicas, como contas vinculadas, serviços, tags ou zonas de disponibilidade.

 Depois de configurar seus limites de orçamento com o AWS Budgets, use [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) para reduzir seu custo inesperado. AWS Cost Anomaly Detection é um serviço de gerenciamento de custos que usa machine learning para monitorar continuamente o custo e o uso a fim de detectar gastos incomuns. Ele ajuda a identificar gastos anômalos e causas raiz, para que você possa agir rapidamente. Primeiro, crie um monitor de custos em AWS Cost Anomaly Detection e depois escolha sua preferência de alerta configurando um limite em dólares (como um alerta sobre anomalias com impacto superior a USD 1 mil). Com o recebimento dos alertas, é possível analisar a causa raiz por trás da anomalia e o impacto em seus custos. Também é possível monitorar e realizar sua própria análise de anomalias em AWS Cost Explorer. 

 Aplique políticas de governança na AWS por meio de [AWS Identity and Access Management](https://aws.amazon.com/iam/) e [AWS Organizations Políticas de controle de serviço (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html). O IAM permite gerenciar com segurança o acesso a serviços e recursos da AWS. Usando o IAM, você pode controlar quem pode criar ou gerenciar recursos da AWS, os tipos de recursos que podem ser criados e onde eles podem ser criados. Isso minimiza a possibilidade de criação de recursos fora da política definida. Use as funções e os grupos criados anteriormente e atribua [políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) para impor o uso correto. A SCP oferece controle central sobre o número máximo de permissões disponíveis para todas as contas na sua organização, garantindo que suas contas permaneçam dentro das diretrizes de controle de acesso. As SCPs estão disponíveis somente em uma organização com todos os recursos habilitados, e você pode configurar as SCPs para negar ou permitir ações para contas membro por padrão. Para ter mais detalhes sobre a implementação do gerenciamento de acesso, consulte o [whitepaper Pilar Segurança do Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html). 

 A governança também pode ser implementada por meio do gerenciamento do [Service Quotas da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html). Ao garantir que o Service Quotas esteja configurado com o mínimo de sobrecarga e mantido com precisão, você pode minimizar a criação de recursos fora dos requisitos da sua organização. Para conseguir isso, você deve entender a rapidez com que seus requisitos podem mudar, compreender projetos em andamento (criação e desativação de recursos) e considerar a rapidez com que as alterações de cota podem ser implementadas. O [Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) pode ser usado para aumentar suas cotas quando necessário. 

**Etapas da implementação**
+ ** Implementar notificações sobre gastos:** Usando suas políticas de organização definidas, crie [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) para ser notificado quando os gastos estiverem fora de suas políticas. Configure vários orçamentos de custos, um para cada conta, que o notifica sobre os gastos gerais da conta. Configure orçamentos de custos adicionais dentro de cada conta para unidades menores dentro da conta. Essas unidades variam de acordo com a estrutura da sua conta. Alguns exemplos comuns são Regiões da AWS, workloads (usando tags) ou serviços da AWS. Configure uma lista de distribuição de e-mails como o destinatário das notificações, e não uma conta de e-mail de uma pessoa. Você pode configurar um orçamento real para quando um valor for ultrapassado ou usar um orçamento previsto para notificar sobre o uso previsto. Você também pode pré-configurar ações de orçamento do AWS que podem aplicar políticas específicas de IAM ou SCP ou interromper Amazon EC2 de destino ou instâncias de Amazon RDS. As ações de orçamento podem ser executadas automaticamente ou exigir aprovação do fluxo de trabalho.
+  **Implementar notificações sobre gastos:** Use o [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) para reduzir seus custos imprevistos em sua organização e analisar a causa raiz de possíveis gastos anômalos. Depois de criar o monitor de custos para identificar gastos incomuns em sua granularidade especificada e configurar notificações em AWS Cost Anomaly Detection, ele envia um alerta quando um gasto incomum é detectado. Isso permitirá que você analise o caso raiz por trás da anomalia e entenda o impacto em seu custo. Use categorias de custo de AWS durante a configuração de AWS Cost Anomaly Detection para identificar qual equipe de projeto ou equipe de unidade de negócios pode analisar a causa raiz do custo inesperado e tomar as ações necessárias em tempo hábil. 
+ ** Implementar controles de uso: **Usando as políticas da organização definidas, implemente políticas e perfis do IAM para especificar quais ações os usuários podem e quais não podem executar. Várias políticas organizacionais podem ser incluídas em uma política da AWS. Da mesma forma que você definiu políticas, comece amplamente e, em seguida, aplique controles mais granulares em cada etapa. Os limites de serviço também são um controle eficaz do uso. Implemente os limites de serviço corretos em todas as suas contas. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Políticas gerenciadas da AWS para funções de trabalho](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html) 
+  [Estratégia de faturamento de várias contas da AWS](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [Controle o acesso a Regiões da AWS usando as políticas do IAM](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 
+  [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 
+  [Controle de custos do AWS](https://aws.amazon.com/getting-started/hands-on/control-your-costs-free-tier-budgets/) 

 **Vídeos relacionados:** 
+  [Como posso usar o AWS Budgets para rastrear meus gastos e uso](https://www.youtube.com/watch?v=Ris23gKc7s0) 

 **Exemplos relacionados:** 
+  [Exemplos de políticas de gerenciamento de acesso do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html) 
+  [Políticas de controle de serviço de exemplo](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) 
+  [Ações de orçamento do AWS](https://aws.amazon.com/blogs/aws-cloud-financial-management/get-started-with-aws-budgets-actions/) 
+  [Criar política do IAM para controlar o acesso aos recursos do Amazon EC2 usando tags](https://aws.amazon.com/premiumsupport/knowledge-center/iam-ec2-resource-tags/) 
+  [Restringir o acesso do Identity do IAM a recursos específicos do Amazon EC2](https://aws.amazon.com/premiumsupport/knowledge-center/restrict-ec2-iam/) 
+  [Criar uma política do IAM para restringir o uso do Amazon EC2 por família](https://www.wellarchitectedlabs.com/cost/200_labs/200_2_cost_and_usage_governance/3_ec2_restrict_family/) 
+  [Laboratórios do Well-Architected: Governança de custo e uso (Nível 100)](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  [Laboratórios do Well-Architected: Governança de custo e uso (Nível 200)](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_2_Cost_and_Usage_Governance/README.html) 
+  [Integrações do Slack para Cost Anomaly Detection usando Amazon Q Developer in chat applications](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/) 

# COST02-BP06 Acompanhar o ciclo de vida do projeto
<a name="cost_govern_usage_track_lifecycle"></a>

 Acompanhe, meça e realize auditorias no ciclo de vida dos projetos, equipes e ambientes para evitar o uso e pagamento de recursos desnecessários. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 O monitoramento eficaz do ciclo de vida do projeto permite que as organizações tenham um controle mais adequado sobre os custos por meio de melhor planejamento, gerenciamento e otimização de recursos, tempo e qualidade. Os insights obtidos por meio do rastreamento são inestimáveis para a tomada de decisões fundamentadas que contribuem para a relação custo-benefício e o sucesso geral do projeto. 

 O rastreamento de todo o ciclo de vida da workload ajuda a compreender quando as workloads ou os respectivos componentes não são mais necessários. As workloads e os componentes existentes podem parecer estar em uso, mas quando a AWS libera novos serviços ou recursos, eles podem ser desativados ou adotados. Confira os estágios anteriores das workloads. Depois que uma workload está em produção, os ambientes anteriores podem ser desativados ou terem a capacidade significativamente reduzida até que sejam necessários novamente. 

 A AWS fornece uma série de serviços de gerenciamento e governança que você pode usar para o rastreamento do ciclo de vida da entidade. É possível usar o [AWS Config](https://aws.amazon.com/config/) ou o [AWS Systems Manager](https://aws.amazon.com/systems-manager/) para fornecer um inventário detalhado da configuração e dos seus recursos da AWS. Recomendamos que você o integre com seus sistemas existentes de gerenciamento de projetos ou ativos para acompanhar projetos e produtos ativos em sua organização. A combinação do seu sistema atual com o conjunto de eventos e métricas avançados fornecido pela AWS permite criar uma visão de eventos de ciclo de vida significativos e gerenciar os recursos proativamente para reduzir os custos desnecessários. 

 De modo semelhante ao [gerenciamento do ciclo de vida da aplicação (ALM)](https://aws.amazon.com/what-is/application-lifecycle-management/), o acompanhamento do ciclo de vida do projeto deve envolver vários processos, ferramentas e equipes que trabalham juntas, como design e desenvolvimento, testes, produção, suporte e redundância de workload. 

 Ao monitorar cuidadosamente cada fase do ciclo de vida de um projeto, as organizações obtêm insights cruciais e um controle aprimorado, o que facilita o sucesso do planejamento, da implementação e da conclusão do projeto. Essa supervisão cuidadosa verifica se os projetos, além de atenderem aos padrões de qualidade, são entregues no prazo e dentro do orçamento, promovendo o custo-benefício de modo geral. 

 Para obter mais informações sobre como implementar o rastreamento do ciclo de vida de entidades, consulte o whitepaper [Pilar Excelência operacional: AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html). 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Estabelecer um processo de monitoramento do ciclo de vida de projetos: ** a [equipe do Centro de Excelência da Nuvem](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_cloud_financial_management_function.html) deve estabelecer o processo de monitoramento do ciclo de vida de projetos. Estabeleça uma abordagem estruturada e sistemática para monitorar as workloads a fim de melhorar o controle, a visibilidade e o desempenho dos projetos. Torne o processo de monitoramento transparente, colaborativo e dedicado à melhoria contínua para maximizar sua eficácia e valor. 
+ ** Realizar análises da workload:** conforme definido por suas políticas organizacionais, configure uma frequência regular para auditar os projetos existentes e realizar análises da workload. A quantidade de esforço utilizado na auditoria deve ser proporcional ao risco aproximado, valor ou custo para a organização. As principais áreas a serem incluídas na auditoria seriam riscos para a organização de um incidente ou interrupção, valor ou contribuição para a organização (medidos em receita ou reputação da marca), custo da carga de trabalho (medido como custo total de recursos e custos operacionais) e uso da carga de trabalho (medido em número de resultados da organização por unidade de tempo). Se essas áreas mudarem ao longo do ciclo de vida, serão necessários ajustes na carga de trabalho, como desativação total ou parcial.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Guidance for Tagging on AWS](https://aws.amazon.com/solutions/guidance/tagging-on-aws/)
+ [ O que é ALM (gerenciamento do ciclo de vida das aplicações)?](https://aws.amazon.com/what-is/application-lifecycle-management/)
+  [Políticas gerenciadas da AWS para funções de trabalho](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html) 

 **Exemplos relacionados:** 
+  [Control access to Regiões da AWS using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 

 **Ferramentas relacionadas:** 
+  [AWS Config](https://aws.amazon.com/config/) 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)

# CUSTOS 3. Como monitorar custos e uso?
<a name="cost-03"></a>

Estabeleça políticas e procedimentos para monitorar e alocar adequadamente os custos. Isso permite medir e aprimorar a eficiência de custos dessa workload.

**Topics**
+ [COST03-BP01 Configurar fontes de informações detalhadas](cost_monitor_usage_detailed_source.md)
+ [COST03-BP02 Adicionar informações da organização ao custo e ao uso](cost_monitor_usage_org_information.md)
+ [COST03-BP03 Identificar categorias de atribuição de custos](cost_monitor_usage_define_attribution.md)
+ [COST03-BP04 Estabelecer métricas da organização](cost_monitor_usage_define_kpi.md)
+ [COST03-BP05 Configurar as ferramentas de faturamento e gerenciamento de custos](cost_monitor_usage_config_tools.md)
+ [COST03-BP06 Alocar custos com base nas métricas de workload](cost_monitor_usage_allocate_outcome.md)

# COST03-BP01 Configurar fontes de informações detalhadas
<a name="cost_monitor_usage_detailed_source"></a>

Configure as ferramentas de gerenciamento de custos e geração de relatórios para detalhamento por hora a fim de fornecer informações detalhadas de custo e uso, bem como aumentar o nível de análise e transparência. Configure a workload para gerar ou receber as entradas de log para cada resultado empresarial entregue.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Informações detalhadas de faturamento, como detalhamento por hora nas ferramentas de gerenciamento de custos, permitem que as organizações acompanhem suas taxas de consumo com mais detalhes e as ajudem a identificar alguns dos motivos do aumento de custos. Essas fontes de dados oferecem a visualização mais precisa do custo e do uso em toda a organização. 

 O AWS Cost and Usage Report fornece detalhamento de uso diário ou por hora, taxas, custos e atributos de uso para todos os serviços da AWS cobráveis. Todas as dimensões possíveis estão no CUR, incluindo marcação, localização, atributos de recurso e IDs de conta. 

 Configure seu CUR com as seguintes personalizações: 
+  Incluir IDs de recurso 
+  Atualizar automaticamente o CUR 
+  Detalhamento por hora 
+  **Versionamento:** Substituir relatório existente 
+  **Integração de dados:** Athena (formato Parquet e compactação) 

 Use [AWS Glue](https://aws.amazon.com/glue/) para preparar os dados para análise e use o [Amazon Athena](https://aws.amazon.com/athena/) para executar a análise de dados, usando SQL para consultar os dados. Você também pode usar o [Quick](https://aws.amazon.com/quicksight/) para criar visualizações personalizadas e complexas e distribuí-las em toda a organização. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Configurar o relatório de custos e uso:** Usando o console de faturamento, configure pelo menos um relatório de custos e uso. Configure um relatório com granularidade por hora que inclua todos os identificadores e IDs de recursos. Você também pode criar outros relatórios com diferentes níveis de detalhamento para fornecer informações resumidas de alto nível. 
+  **Configurar a granularidade por hora no Cost Explorer:** Habilite o **Por hora** e **Dados em nível de recurso** para acessar dados de custo e uso com granularidade por hora nos últimos 14 dias e granularidade em nível de recurso. 
+  **Configurar o registro em log de aplicações:** Verifique se a aplicação registra cada resultado empresarial entregue para que possa ser acompanhado e medido. Verifique se o detalhamento desses dados é pelo menos por hora para que ele corresponda aos dados de custo e uso. Para obter mais detalhes sobre registro em log e monitoramento, consulte [Pilar Excelência operacional do Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) 
+  [AWS Glue](https://aws.amazon.com/glue/) 
+  [Quick](https://aws.amazon.com/quicksight/) 
+  [Definição de preço do Gerenciamento de Custos da AWS](https://aws.amazon.com/aws-cost-management/pricing/) 
+  [Marcação de recursos da AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) 
+  [Análise de custos com o AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Análise de custos com o Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Gerenciamento de AWS Cost and Usage Reports](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 
+  [Pilar Excelência operacional do Well-Architected](https://wa.aws.amazon.com/wat.pillar.operationalExcellence.en.html) 

 **Exemplos relacionados:** 
+  [Configuração da conta da AWS](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html) 
+  [O novo visual e os casos de uso comuns do AWS Cost Explorer](https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-cost-explorers-new-ui-and-common-use-cases/) 

# COST03-BP02 Adicionar informações da organização ao custo e ao uso
<a name="cost_monitor_usage_org_information"></a>

Defina um esquema de marcação com base na sua organização, atributos da workload e categorias de alocação de custos para que você possa filtrar e pesquisar recursos ou monitorar custos e uso em ferramentas de gerenciamento de custos. Implemente marcação consistente em todos os recursos, sempre que possível, por finalidade, equipe, ambiente ou outros critérios relevantes ao seu negócio. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

Implemente [marcação na AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) para adicionar informações da organização aos seus recursos, que serão adicionadas às suas informações de custo e uso. Uma tag é um par de chave-valor. A chave é definida e deve ser exclusiva em toda a organização, e o valor é exclusivo para um grupo de recursos. Um exemplo de par de chave-valor é a chave `Environment`, com um valor de `Production`. Todos os recursos no ambiente de produção terão esse par de chave-valor. A marcação permite categorizar e rastrear seus custos com informações relevantes e significativas da organização. Você pode aplicar tags que representem categorias de organização (como centros de custo, nomes de aplicativos, projetos ou proprietários) e identificar workloads e características de workloads (como teste ou produção) para atribuir seus custos e uso em toda a organização.

Quando você aplica tags aos seus recursos da AWS (como instâncias do Amazon Elastic Compute Cloud ou buckets do Amazon Simple Storage Service) e as ativa, a AWS adiciona essas informações aos Relatórios de Custo e Uso. Você pode gerar relatórios e realizar análises em recursos marcados e não marcados para permitir maior conformidade com políticas internas de gerenciamento de custos e garantir a atribuição precisa.

Criar e implementar um padrão de marcação da AWS em todas as contas da organização permite que você gerencie e administre seus ambientes da AWS de maneira consistente e uniforme. Use as [políticas de tags](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) no AWS Organizations para definir regras de como as tags podem ser usadas em recursos da AWS nas suas contas no AWS Organizations. As políticas de tag permitem que você adote facilmente uma abordagem padronizada para marcar os recursos da AWS.

O [Tag Editor da AWS](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) permite adicionar, excluir e gerenciar tags de vários recursos. Com o Tag Editor, é possível pesquisar os recursos que você deseja marcar e gerenciar as tags para os recursos nos resultados da pesquisa.

As [Categorias de Custos da AWS](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) permitem que você atribua significado da organização aos seus custos, sem exigir tags nos recursos. Você pode mapear suas informações de custo e uso para estruturas internas exclusivas da organização. Você define regras de categoria para mapear e categorizar custos usando dimensões de faturamento, como contas e tags. Isso fornece outro nível de capacidade de gerenciamento, além da marcação. Você também pode mapear contas e tags específicas para vários projetos.

**Etapas da implementação**
+  **Defina um esquema de marcação:** reúna todas as partes interessadas de todo o seu negócio para definir um esquema. Isso geralmente inclui pessoas dos departamentos técnico, financeiro e de gerenciamento. Defina uma lista de tags que todos os recursos devem ter, bem como outra lista com as tags que os recursos podem ter. Verifique se os nomes e valores das tags são consistentes em toda a organização. 
+ **Recursos de tag: **usando suas categorias de atribuição de custos definidas, [coloque tags](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) em todos os recursos em suas workloads de acordo com as categorias. Use ferramentas como CLI, Tag Editor ou AWS Systems Manager para aumentar a eficiência. 
+  **Implemente as Categorias de Custos da AWS: **você pode criar [categorias de custos](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) sem implementar a marcação. As categorias de custos usam as dimensões de custo e uso existentes. Crie regras de categoria a partir do esquema e as implemente nas categorias de custos. 
+  **Automatize a marcação: **para garantir que você mantenha altos níveis de marcação em todos os recursos, automatize a marcação para que os recursos sejam marcados automaticamente quando forem criados. Use serviços como o [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html) para garantir que os recursos sejam marcados quando forem criados. Você também pode criar uma solução personalizada para [marcar automaticamente](https://aws.amazon.com/blogs/mt/auto-tag-aws-resources/) usando as funções do Lambda ou usar um microsserviço que verifica a workload periodicamente e remove todos os recursos que não estão marcados, o que é ideal para ambientes de teste e desenvolvimento. 
+ ** Monitore e relate a marcação: **para garantir que você mantenha altos níveis de marcação em toda a organização, relate e monitore as tags em todas as workloads. Você pode usar o [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) para visualizar o custo de recursos marcados e não marcados ou usar serviços como o [Tag Editor](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). Analise regularmente o número de recursos não marcados com tags e tome medidas para adicionar tags até atingir o nível desejado de marcação. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Práticas recomendadas de marcação ](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+  [Tag de recurso do AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html) 
+  [Categorias de Custos da AWS](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 
+  [Marcação de recursos da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [Análise de custos com o AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Análise de custos com o Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Gerenciamento do Relatório de Custos e Uso da AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

 **Vídeos relacionados:** 
+ [ How can I tag my AWS resources to divide up my bill by cost center or project ](https://www.youtube.com/watch?v=3j9xyyKIg6w)(Como posso marcar meus recursos da AWS para dividir minha fatura por centro de custo ou projeto)
+ [Marcação de recursos da AWS](https://www.youtube.com/watch?v=MX9DaAQS15I)

 **Exemplos relacionados:** 
+ [Marcar automaticamente novos recursos da AWS com base em identidade ou perfil ](https://aws.amazon.com/blogs/mt/auto-tag-aws-resources/)

# COST03-BP03 Identificar categorias de atribuição de custos
<a name="cost_monitor_usage_define_attribution"></a>

 Identifique categorias organizacionais, como unidades de negócios, departamentos ou projetos, que poderiam ser usadas para alocar custos em sua organização às entidades consumidoras internas. Use essas categorias para impor a responsabilidade de gastos, bem como promover o reconhecimento de custos e comportamentos de consumo eficazes. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 O processo de categorização de custos é crucial em orçamentos, contabilidade, relatórios financeiros, tomada de decisão, benchmarking e gerenciamento de projetos. Ao classificar e categorizar as despesas, as equipes podem entender melhor os tipos de custos que gerarão ao longo da jornada para a nuvem, ajudando-as a tomar decisões conscientes e gerenciar orçamentos de forma eficaz. 

 A responsabilidade pelos gastos com a nuvem estabelece um forte incentivo para o gerenciamento disciplinado da demanda e dos custos. O resultado é uma economia significativamente maior nos custos da nuvem para organizações que alocam a maior parte de seus gastos com a nuvem para unidades de negócios ou equipes consumidoras. Além disso, a alocação de gastos na nuvem ajuda as organizações a adotar mais práticas recomendadas de governança centralizada da nuvem. 

 Trabalhe com sua equipe financeira e outras partes interessadas relevantes para entender os requisitos de como os custos devem ser alocados em sua organização durante suas chamadas regulares. Os custos da workload devem ser alocados durante todo o ciclo de vida, incluindo desenvolvimento, teste, produção e desativação. Entenda como os custos incorridos para o aprendizado, o desenvolvimento da equipe e a criação de ideias são atribuídos na organização. Isso pode ser útil para alocar corretamente contas usadas para essa finalidade para orçamentos de treinamento e desenvolvimento, em vez de orçamentos genéricos de custo de TI. 

 Depois de definir as categorias de atribuição de custos com as partes interessadas na organização, use [Categorias de custos da AWS](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) para agrupar as informações de custo e uso em categorias significativas na Nuvem AWS, como custo de um projeto específico ou em Contas da AWS para departamentos ou unidades de negócios. É possível criar categorias personalizadas e mapear as informações de custo e uso nessas categorias com base nas regras definidas usando várias dimensões, como conta, tag, serviço ou tipo de cobrança. Assim que as categorias de custos forem definidas, você verá as informações de custos e uso de acordo com elas, permitindo que a organização tome melhores decisões estratégicas e de compras. Também é possível ver essas categorias no AWS Cost Explorer, no AWS Budgets e no AWS Cost and Usage Report. 

 Por exemplo, é possível criar categorias de custos para suas unidades de negócios (equipe DevOps) e, em cada categoria, criar várias regras (para cada subcategoria) com várias dimensões (Contas da AWS, tags de alocação de custos, serviços ou tipo de cobrança) com base nos seus agrupamentos definidos. Com as categorias de custos, é possível organizar os custos usando um mecanismo baseado em regras. As regras que você configurar organizarão seus custos em categorias. Dentro dessas regras, é possível aplicar filtros usando várias dimensões para cada categoria, como Contas da AWS, serviços da AWS ou tipos de cobrança específicos. Depois, você pode usar essas categorias em vários produtos no console do [Gerenciamento de Faturamento e Custos da AWS e Console de Gerenciamento de Custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-what-is.html) [.](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/view-billing-dashboard.html). Isso inclui AWS Cost Explorer, AWS Budgets, AWS Cost and Usage Report e AWS Cost Anomaly Detection. 

 Como exemplo, o diagrama a seguir mostra como agrupar as informações de custos e uso em sua organização, com várias equipes (categoria de custos), vários ambientes (regras) e vários recursos ou ativos em cada ambiente (dimensões). 

![\[Fluxograma detalhando a relação entre custo e uso em uma organização.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/cost-usage-organization-chart.png)


 

 Também é possível criar agrupamento de custos usando as categorias de custos. Depois de criar as categorias de custos (aguardando até 24 horas após a criação de uma categoria para que seus registros de uso sejam atualizados com valores), elas aparecem no [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/), o [AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html), o [AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)e o [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/). No AWS Cost Explorer e no AWS Budgets, uma categoria de custos aparece como uma dimensão de faturamento adicional. Você pode usar isso para filtrar por valor de categoria de custos específico ou agrupar pela categoria de custos. 

### Etapas para a implementação
<a name="implementation-steps"></a>
+  **Defina as categorias da sua organização:** Reúna-se com as unidades de negócios e as partes interessadas internas para definir categorias que reflitam a estrutura e os requisitos da organização. Essas categorias devem ser associadas diretamente à estrutura das categorias financeiras existentes, como unidade de negócios, orçamento, centro de custo ou departamento. Veja os resultados que a nuvem oferece para a sua empresa, como treinamento ou educação, já que também são categorias de organização. 
+  **Defina suas categorias funcionais:** Reúna-se com as unidades de negócios e as partes interessadas internas para definir categorias que reflitam as funções presentes na empresa. Podem ser os nomes da workload ou do aplicativo e o tipo de ambiente, como produção, teste ou desenvolvimento. 
+  **Defina as Categorias de custos da AWS:** Crie categorias de custo para organizar as informações de custo e uso usando [Categorias de custos da AWS](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) e associe o custo e o uso de recursos da AWS a [categorias significativas](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/create-cost-categories.html). Várias categorias podem ser atribuídas a um recurso, e um recurso pode estar em várias categorias diferentes. Portanto, defina quantas categorias forem necessárias para [gerenciar seus custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) dentro da estrutura categorizada usando Categorias de custos da AWS. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Marcação de recursos da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [Uso de tags de alocação de custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) 
+  [Análise de custos com o AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Análise de custos com o Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Gerenciamento de AWS Cost and Usage Reports](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 
+  [Categorias de custos da AWS](https://docs.aws.amazon.com/wellarchitected/latest/framework/aws-cost-management/aws-cost-categories/) 
+  [Gerenciamento de custos com as Categorias de custos da AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) 
+  [Criação de categorias de custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/create-cost-categories.html) 
+  [Marcação de categorias de custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/tag-cost-categories.html) 
+  [Divisão de cobranças entre as categorias de custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/splitcharge-cost-categories.html) 
+  [Recursos das Categorias de custos da AWS](https://aws.amazon.com/aws-cost-management/aws-cost-categories/features/) 

 **Exemplos relacionados:** 
+  [Organizar seus dados de custos e uso com as Categorias de custos da AWS](https://aws.amazon.com/blogs/aws-cloud-financial-management/organize-your-cost-and-usage-data-with-aws-cost-categories/) 
+  [Gerenciamento de custos com as Categorias de custos da AWS](https://aws.amazon.com/aws-cost-management/resources/managing-your-costs-with-aws-cost-categories/) 
+  [Laboratórios do Well-Architected: Visualização de custo e uso](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  [Laboratórios do Well-Architected: Categorias de custo](https://wellarchitectedlabs.com/cost/200_labs/200_cost_category/) 

# COST03-BP04 Estabelecer métricas da organização
<a name="cost_monitor_usage_define_kpi"></a>

 Estabeleça as métricas da organização que são necessárias para esta carga de trabalho. Exemplo de métricas de uma workload são relatórios de clientes produzidos ou páginas da Web veiculadas aos clientes. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

entenda como a saída da carga de trabalho é medida em relação ao sucesso empresarial. Cada carga de trabalho normalmente tem um pequeno conjunto de saídas principais que indicam performance. Se você tiver uma carga de trabalho complexa com muitos componentes, poderá priorizar a lista ou definir e rastrear métricas para cada componente. Trabalhe com suas equipes para entender quais métricas usar. Essa unidade será usada para compreender a eficiência da carga de trabalho ou o custo de cada saída de negócios.

**Etapas da implementação**
+  **Defina os resultados da workload: **reúna-se com as partes interessadas do negócio e defina os resultados para a workload. Essas são medidas principais de uso do cliente e devem ser métricas de negócios, e não técnicas. Deve haver um pequeno número de métricas de alto nível (menos de cinco) por carga de trabalho. Se a carga de trabalho produzir vários resultados para diferentes casos de uso, agrupe-os em uma única métrica. 
+  **Defina os resultados para os componentes da workload: **opcionalmente, se você tiver uma workload grande e complexa ou puder facilmente dividir sua workload em componentes (como microsserviços) com entradas e saídas bem definidas, defina métricas para cada componente. O esforço deve refletir o valor e o custo do componente. Comece com os maiores componentes e trabalhe em direção aos componentes menores. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Marcação de recursos da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [Análise de custos com o AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Análise de custos com o Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Gerenciamento do Relatório de Custos e Uso da AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

# COST03-BP05 Configurar as ferramentas de faturamento e gerenciamento de custos
<a name="cost_monitor_usage_config_tools"></a>

 Configure as ferramentas de gerenciamento de custos de acordo com as políticas da sua organização para gerenciar e otimizar gastos com a nuvem. Isso inclui serviços, ferramentas e recursos para organizar e rastrear dados de custos e uso, aprimorar o controle por meio de faturamento consolidado e permissão de acesso, melhorar o planejamento por meio de orçamento e previsões, receber notificações ou alertas e reduzir ainda mais os custos com recursos e otimizações de preços. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Para estabelecer uma forte responsabilidade, sua estratégia de conta deve ser considerada primeiro como parte de sua estratégia de alocação de custos. Realize essa tarefa do jeito certo e talvez não precise ir além. Caso contrário, poderá haver inconsciência e outros pontos problemáticos. 

 Para incentivar a responsabilidade pelos gastos com a nuvem, os usuários devem ter acesso a ferramentas que forneçam visibilidade de seus custos e uso. É recomendável que todas as workloads e equipes tenham as ferramentas configuradas para os seguintes detalhes e finalidades: 
+  **Organização:** Estabeleça a alocação de custos e linha de base de governança com sua própria estratégia de marcação e categorizações. 
+  **Organização:** estabeleça a alocação de custos e linha de base de governança com sua própria estratégia de marcação e taxonomia. Marque os recursos compatíveis da AWS e categorize-os de uma maneira que faça sentido com base na estrutura da sua organização (unidades de negócios, departamentos ou projetos). Marque nomes de contas para centros de custo específicos e mapeie-os com Categorias de Custos da AWS para agrupar contas de unidades de negócios específicas nos centros de custo, para que o proprietário da unidade de negócios possa ver o consumo de várias contas em um só lugar. 
+  **Acesso:** acompanhe as informações de faturamento de toda a organização no [faturamento consolidado](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) e verifique se as partes interessadas e os proprietários de negócios certos têm acesso. 
+  **Controle:** Crie mecanismos de governança eficazes com as barreiras de proteção certas para evitar cenários inesperados ao usar políticas de controle de serviços (SCPs), políticas de tags e alertas de orçamento. Por exemplo, você pode permitir que as equipes criem recursos nas regiões preferidas usando somente mecanismos de controle eficazes. 
+  **Estado atual:** configure um painel mostrando os níveis atuais de custo e uso. O painel deve estar disponível em um local altamente visível dentro do ambiente de trabalho semelhante a um painel de operações. Você pode usar o [Painel de inteligência em nuvem (CID)](https://github.com/aws-samples/aws-cudos-framework-deployment) ou qualquer outro produto compatível para criar essa visibilidade. 
+  **Notificações:** forneça notificações quando o custo ou o uso estiverem fora dos limites definidos e quando ocorrerem anomalias com o AWS Budgets ou o AWS Cost Anomaly Detection. 
+  **Relatórios:** Resuma todas as informações de custos e uso e aumente a conscientização e a responsabilidade sobre seus gastos com a nuvem com dados de custos atribuíveis, detalhados e alocáveis. Os relatórios devem ser relevantes para a equipe que os consome e, preferencialmente, devem conter recomendações. 
+  **Rastreamento:** mostra o custo e o uso atuais em relação a metas ou objetivos configurados. 
+  **Análises:** permita que os membros da equipe realizem análises personalizadas e detalhadas até a granularidade horária, com todas as dimensões possíveis. 
+  **Inspeção:** mantenha-se atualizado com suas oportunidades de implantação de recursos e otimização de custos. Receba notificações (usando o Amazon CloudWatch, o Amazon SNS ou o Amazon SES) para implantações de recursos na organização e analise as recomendações de otimização de custos (por exemplo, AWS Compute Optimizer ou AWS Trusted Advisor). 
+  **Tendências:** exiba a variabilidade de custo e uso ao longo do período necessário, com a granularidade necessária. 
+  **Previsões:** mostre os custos futuros estimados, faça uma estimativa do uso de recursos e gaste com painéis de previsão criados por você. 

 Você pode usar ferramentas da AWS, como [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/), o [Gerenciamento de Faturamento e Custos da AWS](https://aws.amazon.com/aws-cost-management/aws-billing/)ou [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) para o essencial, ou você pode integrar dados CUR com [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway) e o [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway) para fornecer esse recurso para visualizações mais detalhadas. Se você não tem habilidades essenciais ou largura de banda em sua organização, pode trabalhar com o [AWS ProServ](https://aws.amazon.com/professional-services/), [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/)ou [AWS Partners](https://aws.amazon.com/partners/) e usar suas ferramentas. Você também pode usar ferramentas de terceiros. Porém, verifique primeiro se o custo agrega valor à sua organização. 

### Etapas para a implementação
<a name="implementation-steps"></a>
+  **Permita o acesso baseado em equipe às ferramentas:** Configure suas contas e crie grupos que tenham acesso aos relatórios de custo e uso necessários para o consumo e o uso [AWS Identity and Access Management](https://aws.amazon.com/iam/) para [controlar o acesso](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html) a ferramentas, como o AWS Cost Explorer. Esses grupos devem incluir representantes de todas as equipes que possuem ou gerenciam um aplicativo. Isso garante que cada equipe tenha acesso às próprias informações de custo e uso para rastrear seu consumo. 
+  **Configurar o AWS Budgets:** [Configure o AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) em todas as contas das workloads. Defina orçamentos para o gasto geral da conta e orçamentos para as workloads usando tags. Configure notificações no AWS Budgets para receber alertas quando você exceder valores orçados ou quando seus custos estimados excederem seus orçamentos. 
+  **Configure o AWS Cost Explorer:** Configure o [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) para sua workload e contas para visualizar seus dados de custos para análise posterior. Crie um painel para a workload que rastreie o gasto geral, as principais métricas de uso da workload e a previsão de custos futuros com base nos seus dados de custo históricos. 
+  **Configure o AWS Cost Anomaly Detection:** Use o [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) para as contas, os serviços centrais ou as categorias de custos criadas para monitorar os custos e o uso e detectar gastos incomuns. Você pode receber alertas individualmente em relatórios agregados, assim como alertas por e-mail ou em um tópico do Amazon SNS, o que permite analisar e determinar a causa-raiz de uma anomalia e identificar o fator que está aumentando o custo. 
+  **Configure ferramentas avançadas:** Como opção, você pode criar ferramentas personalizadas para a organização que forneçam detalhes e granularidade adicionais. Você pode implementar o recurso de análise avançada usando o [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway)e painéis usando o [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway). Pense no uso da [Solução CID](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) que tem painéis pré-configurados e avançados. Há também [AWS Partners](https://aws.amazon.com/marketplace/solutions/business-applications/cloud-cost-management) com quem você pode trabalhar e adotar as soluções de gerenciamento de nuvem deles para habilitar o monitoramento e a otimização de faturas de nuvem em um local conveniente. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Gerenciamento de custos da AWS](https://docs.aws.amazon.com/cost-management/latest/userguide/what-is-costmanagement.html) 
+  [Marcação](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) Recursos da AWS 
+  [Análise de custos com o AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Análise de custos com o Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Managing AWS Cost and Usage Report](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 
+  [Categorias de custos da AWS](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 
+  [Gerenciamento financeiro na nuvem com a AWS](https://aws.amazon.com/aws-cost-management/) 
+  [Políticas de controle de serviço de exemplo](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) 
+  [AWS APN Partners – Cost Management](https://aws.amazon.com/marketplace/solutions/business-applications/cloud-cost-management) 

 **Vídeos relacionados:** 
+  [Deploying Cloud Intelligence Dashboards (Implantação de painéis de inteligência de nuvem)](https://www.youtube.com/watch?v=FhGZwfNJTnc) 
+  [Get Alerts on any FinOps or Cost Optimization Metric or KPI (Receber alertas sobre qualquer FinOps ou métrica de otimização de custos ou KPI)](https://www.youtube.com/watch?v=dzRKDSXCtAs) 

 **Exemplos relacionados:** 
+  [Laboratórios do Well-Architected: Configuração da conta da AWS](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html/) 
+  [Laboratórios do Well-Architected: Visualização do faturamento](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html) 
+  [Laboratórios do Well-Architected: Governança de custo e uso](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  [Laboratórios do Well-Architected: Análise de custo e uso](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_4_Cost_and_Usage_Analysis/README.html) 
+  [Laboratórios do Well-Architected: Visualização de custo e uso](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  [Laboratórios do Well-Architected: Painéis de inteligência de nuvem](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) 
+  [Como usar SCPs para definir barreiras de proteção de permissão nas contas](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/) 

# COST03-BP06 Alocar custos com base nas métricas de workload
<a name="cost_monitor_usage_allocate_outcome"></a>

Aloque os custos da workload por métricas de uso ou resultados de negócios para medir a eficiência de custos da workload. Implemente um processo para analisar os dados de custo e uso com serviços de análise, que podem fornecer informações e capacidade de estorno.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação para implementação
<a name="implementation-guidance"></a>

A otimização de custos está fornecendo resultados de negócios com o menor preço, que só pode ser alcançado ao alocar custos de workload por métricas de workload (medidas pela eficiência da workload). Monitore as métricas de carga de trabalho definidas por meio de arquivos de log ou outro monitoramento de aplicativos. Combine esses dados com os custos da carga de trabalho, que podem ser obtidos examinando os custos com um valor de tag específico ou ID de conta. É recomendável executar essa análise no nível por hora. Sua eficiência normalmente mudará se você tiver alguns componentes de custo estático (por exemplo, um banco de dados de back-end em execução de maneira permanente) com uma taxa de solicitações variável (por exemplo, picos de uso entre 9h e 17h, com poucas solicitações à noite). Entender a relação entre os custos estáticos e variáveis ajudará você a concentrar suas atividades de otimização. 

 Criar métricas de workload para recursos compartilhados pode ser um desafio em comparação a recursos, como aplicações em contêineres no Amazon Elastic Container Service (Amazon ECS) e no Amazon API Gateway. No entanto, existem algumas maneiras de categorizar o uso e rastrear os custos. Se precisar monitorar recursos compartilhados do Amazon ECS e do AWS Batch, você poderá habilitar os dados de alocação de custos divididos no AWS Cost Explorer. Com dados de alocação de custos divididos, você pode entender e otimizar o custo e o uso de suas aplicações em contêineres e alocar os custos das aplicações para entidades comerciais individuais com base na forma como os recursos compartilhados de computação e memória são consumidos. Se você compartilhou o uso da função do API Gateway e do AWS Lambda, poderá usar o [AWS Application Cost Profiler](https://docs.aws.amazon.com/application-cost-profiler/latest/userguide/introduction.html) para categorizar seu consumo com base em seu `ID do locatário` ou `ID do cliente`. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Aloque custos para métricas de workload:** Usando as métricas definidas e a tags configuradas, crie uma métrica que combine a saída e o custo da workload. Use serviços de análise, como o Amazon Athena e o Amazon Quick, para criar um painel de eficiência para a workload geral e todos os componentes. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Marcação de recursos da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [Análise de custos com o AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Análise de custos com o Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Gerenciamento do Relatório de custos e uso da AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

 **Exemplos relacionados:** 
+ [ Melhore a visibilidade de custos do Amazon ECS e do AWS Batch com dados de alocação de custos divididos da AWS. ](https://aws.amazon.com/blogs/aws-cloud-financial-management/la-improve-cost-visibility-of-containerized-applications-with-aws-split-cost-allocation-data-for-ecs-and-batch-jobs/)

# CUSTOS 4. Como desativar os recursos?
<a name="cost-04"></a>

Implemente o controle de alterações e o gerenciamento de recursos, desde o início do projeto até o fim da vida útil. Isso garante o desligamento ou encerramento dos recursos não utilizados para reduzir o desperdício.

**Topics**
+ [COST04-BP01 Acompanhar os recursos ao longo da vida útil](cost_decomissioning_resources_track.md)
+ [COST04-BP02 Implementar um processo de desativação](cost_decomissioning_resources_implement_process.md)
+ [COST04-BP03 Desativar recursos](cost_decomissioning_resources_decommission.md)
+ [COST04-BP04 Desativar recursos automaticamente](cost_decomissioning_resources_decomm_automated.md)
+ [COST04-BP05 Reforçar políticas de retenção de dados](cost_decomissioning_resources_data_retention.md)

# COST04-BP01 Acompanhar os recursos ao longo da vida útil
<a name="cost_decomissioning_resources_track"></a>

 Defina e implemente um método para acompanhar recursos e suas associações com sistemas ao longo da vida útil. Você pode usar a marcação para identificar a workload ou a função do recurso. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

Desative recursos de workload que não são mais necessários. Um exemplo comum são os recursos usados para testes: após a conclusão do teste, os recursos podem ser removidos. O rastreamento de recursos com tags (e execução de relatórios sobre essas tags) pode ajudar a identificar ativos para desativação, pois eles não estarão em uso ou a licença deles expirará. Usar tags é uma maneira eficaz de rastrear recursos, rotulando o recurso com sua função ou uma data conhecida em que ele pode ser desativado. Os relatórios podem ser executados nessas tags. Os valores de exemplo para marcação de recursos são `testes de feature-X` para identificar a finalidade do recurso em termos de ciclo de vida da workload. Outro exemplo consiste em usar o `LifeSpan` ou `TTL` para os recursos, como nome e valor da chave de tag a ser excluída para definir o período ou o tempo específico para desativação. 

**Etapas da implementação**
+ ** Implementar um esquema de marcação: **Implemente um esquema de marcação que identifique a workload à qual o recurso pertence, garantindo que todos os recursos dentro da workload sejam marcados da maneira apropriada. A marcação ajuda a categorizar os recursos por finalidade, equipe, ambiente ou outros critérios relevantes para o seu negócio. Para obter mais detalhes sobre casos de uso, estratégias e técnicas de marcação, consulte [Práticas recomendadas de marcação de AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html).
+ ** Implementar o monitoramento da saída ou do throughput da workload: **Implemente monitoramento ou alarme de throughput da workload, acionando solicitações de entrada ou conclusões de saída. Configure-o para fornecer notificações quando saídas ou solicitações de workload caírem para zero, indicando que os recursos de workload não são mais usados. Incorpore um fator de tempo se a workload cair periodicamente para zero em condições normais. Para obter mais detalhes sobre recursos não utilizados ou subutilizados, consulte [Verificações de otimização de custos de AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html).
+  **Agrupar recursos do AWS:** Crie grupos para recursos do AWS. Você pode usar o [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) para organizar e gerenciar seus recursos do AWS que estão no mesmo Região da AWS. Você pode adicionar tags à maioria de seus recursos para ajudar a identificá-los e classificá-los em sua organização. Use [Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) para adicionar tags aos recursos compatíveis em massa. Considere o uso de [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/index.html) para criar, gerenciar e distribuir portfólios de produtos aprovados para usuários finais e gerenciar o ciclo de vida do produto. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [Verificações de otimização de custos do AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html) 
+  [Marcação de recursos da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [Publicar métricas personalizadas](https://docs.aws.amazon.com/Amazon/latest/monitoring/publishingMetrics.html) 

 **Vídeos relacionados:** 
+  [Como otimizar custos usando AWS Trusted Advisor](https://youtu.be/zcQPufNFhgg) 

 **Exemplos relacionados:** 
+  [Organização de recursos de AWS](https://aws.amazon.com/premiumsupport/knowledge-center/resource-groups/) 
+  [Otimização do custo usando AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/knowledge-center/trusted-advisor-cost-optimization/) 

# COST04-BP02 Implementar um processo de desativação
<a name="cost_decomissioning_resources_implement_process"></a>

 Implemente um processo para identificar e desativar recursos não utilizados. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

Implemente um processo padronizado em toda a organização para identificar e remover recursos não utilizados. O processo deve definir a frequência das pesquisas e os processos para remover o recurso para verificar se todos os requisitos da organização foram atendidos.

**Etapas da implementação**
+  **Criar e implementar um processo de desativação:** Trabalhe com os proprietários e desenvolvedores de workloads e crie um processo de desativação para a workload e os recursos dela. O processo deve abranger o método para verificar se a workload está em uso e também se cada um dos recursos da workload está em uso. Detalhe as etapas necessárias para desativar o recurso, removendo-os do serviço e garantindo a conformidade com os requisitos normativos. Todos os recursos associados, como licenças ou armazenamento anexado, devem ser incluídos. Notifique os proprietários da workload de que o processo de desativação foi executado. 

   Use as seguintes etapas de desativação para obter orientações sobre o que deve ser verificado como parte do seu processo: 
  +  **Identificar os recursos a serem desativados:** Identifique os recursos elegíveis para desativação em seu Nuvem AWS. Registre todas as informações necessárias e agende a desativação. Em sua linha do tempo, certifique-se de considerar se (e quando) problemas inesperados surgirem durante o processo. 
  +  **Coordenar e comunicar:** Trabalhe com os proprietários da workload para confirmar o recurso a ser desativado 
  +  **Registrar metadados e criar backups:** Registre metadados (como IPs públicos, região, AZ, VPC, sub-rede e grupos de segurança) e crie backups (como snapshots do Amazon Elastic Block Store ou obtenção de AMI, exportação de chaves e exportação de certificado) se for necessário para os recursos no ambiente de produção ou se forem recursos críticos. 
  +  **Validar a infraestrutura como código:** Determine se os recursos foram implantados com o CloudFormation, Terraform, AWS Cloud Development Kit (AWS CDK) ou qualquer outra ferramenta de implantação de infraestrutura como código para que possam ser reimplantados, se necessário. 
  +  **Impedir acesso:** Aplique controles restritivos por um período, para evitar o uso de recursos enquanto você determina se o recurso é necessário. Verifique se o ambiente de recursos pode ser revertido para seu estado original, se necessário. 
  +  **Seguir seu processo de desativação interno:** Siga as tarefas administrativas e o processo de desativação de sua organização, como remover o recurso do domínio da organização, remover o registro DNS e remover o recurso de sua ferramenta de gerenciamento de configuração, ferramenta de monitoramento, ferramenta de automação e ferramentas de segurança. 

   Se o recurso for uma instância do Amazon EC2, consulte a lista a seguir. [Para obter mais detalhes, consulte Como faço para excluir ou terminar meus recursos do Amazon EC2?](https://aws.amazon.com/premiumsupport/knowledge-center/delete-terminate-ec2/) 
  +  Interrompa ou encerre todas as suas instâncias do Amazon EC2 e balanceadores de carga. As instâncias do Amazon EC2 ficam visíveis no console por um curto período após serem finalizadas. Você não será cobrado por instâncias que não estiverem em estado de execução 
  +  Exclua sua infraestrutura do Auto Scaling. 
  +  Libere todos os hosts dedicados. 
  +  Exclua todos os volumes do Amazon EBS e snapshots do Amazon EBS. 
  +  Libere todos os endereços IP elásticos. 
  +  Cancele o registro das imagens de máquina da Amazon (AMIs). 
  +  Encerre todos os ambientes do AWS Elastic Beanstalk. 

   Se o recurso for um objeto armazenado no Amazon Glacier e se você excluir um arquivo antes de atingir a duração mínima de armazenamento, será cobrada uma taxa proporcional de exclusão antecipada. A duração mínima do armazenamento do Amazon Glacier depende da classe de armazenamento usada. Para obter um resumo da duração mínima de armazenamento para cada classe de armazenamento, consulte [Desempenho nas classes de armazenamento do Amazon S3](https://aws.amazon.com/s3/storage-classes/?nc=sn&loc=3#Performance_across_the_S3_Storage_Classes). Para obter detalhes sobre como as taxas de exclusão antecipada são calculadas, consulte [Definição de preço do Amazon S3](https://aws.amazon.com/s3/pricing/). 

 O fluxograma simples do processo de desativação a seguir descreve as etapas de desativação. Antes de desativar recursos, verifique se os recursos que você identificou para desativação não estão sendo usados pela organização. 

![\[Flow chart depicting the steps of decommissioning a resource.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/decommissioning-process-flowchart.png)


## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 

 **Vídeos relacionados:** 
+  [Excluir pilha do CloudFormation, mas reter alguns recursos](https://www.youtube.com/watch?v=bVmsS8rjuwk) 
+  [Descubra qual usuário iniciou a instância do Amazon EC2](https://www.youtube.com/watch?v=SlyAHc5Mv2A) 

 **Exemplos relacionados:** 
+  [Excluir ou terminar recursos do Amazon EC2](https://aws.amazon.com/premiumsupport/knowledge-center/delete-terminate-ec2/) 
+  [Descubra qual usuário iniciou uma instância do Amazon EC2](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-user-launched-instance/) 

# COST04-BP03 Desativar recursos
<a name="cost_decomissioning_resources_decommission"></a>

 Desative recursos acionados por eventos, como auditorias periódicas ou alterações no uso. Em geral, a desativação pode ser realizada periodicamente e é manual ou automatizada. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

a frequência e o esforço para pesquisar recursos não utilizados devem refletir as possíveis economias, portanto, uma conta com um custo pequeno deve ser analisada com menos frequência do que uma conta com custos maiores. Pesquisas e eventos de desativação podem ser acionados por alterações de estado na workload, como um produto que termina a vida útil ou é substituído. Pesquisas e eventos de desativação também podem ser acionados por eventos externos, como alterações nas condições de mercado ou encerramento do produto.

**Etapas da implementação**
+  **Desativar recursos: **Esta é a fase de depreciação de recursos do AWS que não são mais necessários ou término de um contrato de licenciamento. Conclua todas as verificações finais concluídas antes de passar para o estágio de descarte e desativação de recursos para evitar interrupções indesejadas, como tirar snapshots ou backups. Usando o processo de desativação, desative cada um dos recursos que foram identificados como não utilizados.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 

 **Exemplos relacionados:** 
+  [ Laboratórios do Well-Architected: Recursos de desativação (Nível 100) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/) 

# COST04-BP04 Desativar recursos automaticamente
<a name="cost_decomissioning_resources_decomm_automated"></a>

 Projete a workload para lidar normalmente com o encerramento de recursos ao identificar e desativar recursos não críticos, que não são necessários ou com baixa utilização. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

Use a automação para reduzir ou remover os custos associados do processo de desativação. Projetar sua workload para executar a desativação automatizada reduzirá os custos gerais da workload durante sua vida útil. É possível usar o [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) para realizar o processo de desativação. Você também pode implementar código personalizado usando a [API ou o SDK](https://aws.amazon.com/developer/tools/) para desativar recursos de workload automaticamente.

 As [aplicações modernas](https://aws.amazon.com/modern-apps/) são desenvolvidas sem servidor como prioridade, uma estratégia que prioriza a adoção de serviços sem servidor. O AWS desenvolveu [serviços sem servidor](https://aws.amazon.com/serverless/) para todas as três camadas de sua pilha: computação, integração e armazenamento de dados. O uso da arquitetura sem servidor permitirá que você economize custos durante períodos de baixo tráfego com aumento e redução automáticos. 

**Etapas da implementação**
+ ** Implementar o AWS Auto Scaling: **Para recursos compatíveis, configure-os com o [AWS Auto Scaling](https://aws.amazon.com/autoscaling/). O AWS Auto Scaling pode ajudar você a otimizar sua utilização e eficiência de custos ao consumir serviços do AWS. Quando a demanda cair, o AWS Auto Scaling removerá automaticamente qualquer excesso de capacidade de recursos para evitar gastos excessivos.
+ ** Configurar o CloudWatch para encerrar instâncias:** As instâncias podem ser configuradas para encerrar usando [alarmes de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingTerminateActions). Usando as métricas do processo de desativação, implemente um alarme com uma ação do Amazon Elastic Compute Cloud. Verifique a operação em um ambiente que não seja de produção antes de implantar. 
+  **Implementar o código na workload:** Você pode usar o SDK do AWS ou AWS CLI para desativar recursos de workload. Implemente código dentro da aplicação que se integra à AWS e encerre ou remova recursos não mais usados. 
+  **Usar serviços sem servidor:** Priorize a criação de [arquiteturas sem servidor](https://aws.amazon.com/serverless/) e [arquitetura baseada em eventos](https://aws.amazon.com/event-driven-architecture/) no AWS para criar e executar seus aplicativos. O AWS oferece vários serviços de tecnologia sem servidor que fornecem inerentemente a utilização de recursos otimizada automaticamente e a desativação automatizada (aumentar e reduzir a escala horizontalmente). Com aplicativos sem servidor, a utilização de recursos é otimizada automaticamente e você nunca paga por provisionamento em excesso. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [Tecnologia sem servidor no AWS](https://aws.amazon.com/serverless/) 
+  [Crie alarmes para interromper, encerrar, reinicializar ou recuperar uma instância](https://docs.aws.amazon.com/Amazon/latest/monitoring/UsingAlarmActions.html) 
+  [Conceitos básicos do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Adição de ações de encerramento para alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingTerminateActions) 

 **Exemplos relacionados:** 
+  [Agendamento de exclusão automática de pilhas do AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/scheduling-automatic-deletion-of-aws-cloudformation-stacks/) 
+  [ Laboratórios do Well-Architected: Recursos de desativação automática (Nível 100) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/) 
+  [Limpeza automatizada da AWS/Servian](https://github.com/servian/aws-auto-cleanup) 

# COST04-BP05 Reforçar políticas de retenção de dados
<a name="cost_decomissioning_resources_data_retention"></a>

 Defina as políticas de retenção de dados em recursos compatíveis para lidar com exclusão de objetos de acordo com os requisitos de suas organizações. Identifique e exclua recursos e objetos desnecessários ou órfãos que não sejam mais necessários. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

 Use políticas de retenção de dados e de ciclo de vida para reduzir os custos associados do processo de desativação e de armazenamento dos recursos identificados. A definição de suas políticas de retenção de dados e de ciclo de vida para realizar a exclusão e a migração automatizadas de classe de armazenamento reduzirá os custos gerais de armazenamento durante seu tempo de vida. Você pode usar o Amazon Data Lifecycle Manager para automatizar a criação e a exclusão de snapshots do Amazon Elastic Block Store e imagens de máquina (AMIs) baseadas no Amazon EBS, e o Amazon S3 Intelligent-Tiering ou uma configuração de ciclo de vida do Amazon S3 para gerenciar o ciclo de vida de seus objetos do Amazon S3. Você também pode implementar código personalizado usando a [API ou o SDK](https://aws.amazon.com/tools/) para criar políticas de ciclo de vida e regras de políticas para objetos a serem excluídos de forma automática. 

 **Etapas da implementação** 
+  **Uso do Amazon Data Lifecycle Manager:** use políticas de ciclo de vida no Amazon Data Lifecycle Manager para automatizar a exclusão de snapshots do Amazon EBS e AMIs baseadas no Amazon EBS. 
+  **Definição da configuração do ciclo de vida em um bucket:** use a configuração do ciclo de vida do Amazon S3 em um bucket para definir ações a serem realizadas pelo Amazon S3 durante o ciclo de vida de um objeto, bem como a exclusão no final do ciclo de vida do objeto, com base nos requisitos de sua empresa. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/dlm/?icmpid=docs_homepage_mgmtgov) 
+  [How to set lifecycle configuration on Amazon S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html) (Como definir a configuração de ciclo de vida em um bucket do Amazon S3) 

 **Vídeos relacionados:** 
+  [Automate Amazon EBS Snapshots with Amazon Data Lifecycle Manager](https://www.youtube.com/watch?v=RJpEjnVSdi4) (Automatizar snapshots do Amazon EBS com o Amazon Data Lifecycle Manager) 
+  [Empty an Amazon S3 bucket using a lifecycle configuration rule](https://www.youtube.com/watch?v=JfK9vamen9I) (Esvaziar um bucket do Amazon S3 com o uso de uma regra de configuração de ciclo de vida) 

 **Exemplos relacionados:** 
+  [Empty an Amazon S3 bucket using a lifecycle configuration rule](https://aws.amazon.com/premiumsupport/knowledge-center/s3-empty-bucket-lifecycle-rule/) (Esvaziar um bucket do Amazon S3 com o uso de uma regra de configuração de ciclo de vida) 
+  [Laboratório do Well-Architected: Recursos de desativação automática (Nível 100)](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/) 

# Recursos econômicos
<a name="a-cost-effective-resources"></a>

**Topics**
+ [CUSTOS 5. Como avaliar o custo ao selecionar serviços?](cost-05.md)
+ [CUSTOS 6. Como atingir as metas de custo ao selecionar tamanho, número e tipo de recurso?](cost-06.md)
+ [CUSTOS 7. Como usar os modelos de definição de preço para reduzir custos?](cost-07.md)
+ [CUSTOS 8. Como planejar as cobranças de transferência de dados?](cost-08.md)

# CUSTOS 5. Como avaliar o custo ao selecionar serviços?
<a name="cost-05"></a>

O Amazon EC2, o Amazon EBS e o Amazon S3 são serviços fundamentais da AWS. Serviços gerenciados, como o Amazon RDS e o Amazon DynamoDB, são serviços da AWS de nível superior ou em nível de aplicação. Ao selecionar os produtos fundamentais e os serviços gerenciados adequados, você pode otimizar os custos dessa carga de trabalho. Por exemplo, usando serviços gerenciados, é possível reduzir ou remover grande parte da sobrecarga administrativa e operacional, liberando você para trabalhar em aplicativos e atividades relacionadas a negócios.

**Topics**
+ [COST05-BP01 Identificar os requisitos de custos da organização](cost_select_service_requirements.md)
+ [COST05-BP02 Analisar todos os componentes da workload](cost_select_service_analyze_all.md)
+ [COST05-BP03 Executar uma análise completa de cada componente](cost_select_service_thorough_analysis.md)
+ [COST05-BP04 Selecionar software com licenciamento econômico](cost_select_service_licensing.md)
+ [COST05-BP05 Selecionar os componentes desta workload para otimizar o custo alinhado com as prioridades da organização](cost_select_service_select_for_cost.md)
+ [COST05-BP06 Realizar análises de custos para diferentes usos ao longo do tempo](cost_select_service_analyze_over_time.md)

# COST05-BP01 Identificar os requisitos de custos da organização
<a name="cost_select_service_requirements"></a>

 Trabalhe com os membros da equipe para definir o equilíbrio entre otimização de custos e outros pilares, como performance e confiabilidade, para essa carga de trabalho. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Na maioria das organizações, o departamento de tecnologia da informação (TI) é composto de várias equipes pequenas, cada uma com sua própria agenda e área de foco, que refletem as especialidades e as habilidades dos respectivos membros. Você precisa compreender os objetivos, as prioridades e as metas gerais da organização e como cada departamento ou projeto contribui para esses objetivos. A categorização de todos os recursos essenciais, incluindo pessoal, equipamentos, tecnologia, materiais e serviços externos, é crucial para alcançar os objetivos organizacionais e um planejamento orçamentário abrangente. A adoção dessa abordagem sistemática para a identificação e a compreensão dos custos é fundamental para estabelecer um plano de custos realista e robusto para a organização. 

 ao selecionar serviços para a sua carga de trabalho, é fundamental compreender as prioridades da sua organização. Crie um equilíbrio entre a otimização de custos e outros pilares do AWS Well-Architected Framework, como desempenho e confiabilidade. Esse processo deve ser conduzido de forma sistemática e regular para refletir as mudanças nos objetivos da organização, nas condições de mercado e na dinâmica operacional. Uma carga de trabalho totalmente otimizada para custo é a solução mais alinhada aos requisitos da sua organização, não necessariamente o menor custo. Reúna-se com todas as equipes da organização, como produtos, negócios, técnicas e finanças, para coletar as informações. Avalie o impacto das compensações entre interesses concorrentes ou abordagens alternativas para ajudar a tomar decisões fundamentadas ao determinar onde concentrar as iniciativas ou escolher um plano de ação. 

 Por exemplo, a aceleração da velocidade de entrada no mercado de novos recursos pode ser enfatizada em relação à otimização de custos, ou você pode escolher um banco de dados relacional para dados não relacionais para simplificar o esforço de migração de um sistema, em vez de migrar para um banco de dados otimizado para seu tipo de dados e atualizar a aplicação. 

### Etapas da implementação
<a name="implementation-steps"></a>
+ **Identificar as necessidades de custos da organização:** reúna-se com os membros das equipes da organização, incluindo aqueles em gerenciamento de produtos, proprietários de aplicações, equipes de desenvolvimento e de operações, gerenciamento e finanças. Priorize os pilares do Well-Architected para essa workload e os respectivos componentes. O resultado deve ser uma lista ordenada dos pilares. Também é possível adicionar um peso a cada pilar para indicar quanto foco adicional ele tem ou quão semelhantes são os focos entre dois pilares.
+  **Abordar a dívida técnica e documentá-la:** durante a análise da workload, aborde a dívida técnica. Documente um item de backlog para revisitar a workload no futuro, com o objetivo de refatorar ou rearquitetar para otimizá-la ainda mais. É essencial comunicar claramente as compensações feitas para outras partes interessadas. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [REL11-BP07 Arquitetar o produto para cumprir as metas de disponibilidade e os acordos de nível de serviço (SLAs) de tempo de atividade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_service_level_agreements.html)
+ [ OPS01-BP06 Avalie as compensações ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)

 **Documentos relacionados:** 
+  [AWS Total Cost of Ownership (TCO) Calculator](https://aws.amazon.com/tco-calculator/) (Calculadora de custo total de propriedade (TCO) da AWS) 
+  [Categorias de armazenamento do Amazon S3](https://aws.amazon.com/s3/storage-classes/) 
+  [Produtos da nuvem](https://aws.amazon.com/products/) 

# COST05-BP02 Analisar todos os componentes da workload
<a name="cost_select_service_analyze_all"></a>

 Verifique se cada componente da workload é analisado, independentemente do tamanho ou dos custos atuais. O trabalho da análise deve refletir o benefício em potencial, como os custos atuais e projetados. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Os componentes da workload, projetados para agregar valor comercial à organização, podem abranger vários serviços. Para cada componente, é possível escolher serviços específicos da Nuvem AWS para atender às necessidades dos negócios. Essa seleção pode ser influenciada por fatores como a familiaridade ou a experiência anterior com esses serviços. 

 Depois de identificar os requisitos da organização (conforme mencionado em [COST05-BP01 Identificar os requisitos de custos da organização](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_select_service_requirements.html)), faça uma análise completa de todos os componentes da workload. Analise cada componente considerando os custos e os tamanhos atuais e projetados. Considere o custo da análise em relação a qualquer possível economia da workload ao longo do respectivo ciclo de vida. O trabalho despendido na análise de todos os componentes dessa workload deve corresponder às possíveis economias ou melhorias previstas da otimização desse componente específico. Por exemplo, se o custo do recurso proposto for USD 10/mês e, sob as cargas previstas, não excederem USD 15/mês, gastar um dia de trabalho para reduzir os custos em 50% (USD 5 por mês) poderá exceder o benefício em potencial durante a vida útil do sistema. O uso de uma estimativa baseada em dados mais rápida e eficiente criará o melhor resultado geral para esse componente. 

 As workloads podem mudar ao longo do tempo, e o conjunto certo de serviços poderá não ser ideal se a arquitetura da workload ou o uso mudar. A análise para seleção de serviços deve incorporar estados de carga de trabalho e níveis de uso atuais e futuros. A implementação de um serviço para o estado ou uso futuro da carga de trabalho pode reduzir os custos gerais ao reduzir ou remover o esforço necessário para fazer alterações futuras. Por exemplo, o uso do Amazon EMR Serverless pode ser a escolha apropriada inicialmente. No entanto, à medida que o consumo desse serviço aumenta, a transição para o Amazon EMR no Amazon EC2 pode reduzir os custos desse componente da workload. 

 A análise estratégica de todos os componentes da workload, independentemente de seus atributos atuais, tem o potencial de gerar melhorias notáveis e economias financeiras ao longo do tempo. O esforço investido nesse processo de análise deve ser deliberado, com consideração cuidadosa das vantagens que podem ser obtidas. 

 O [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) e o [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) (CUR) podem analisar o custo de uma prova de conceito (PoC) ou do ambiente em execução. Também é possível usar o [AWS Calculadora de Preços](https://calculator.aws/#/) para estimar os custos da workload. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Listar os componentes da workload:** crie uma lista dos componentes da workload. Ela é usada para a verificação de que cada componente foi analisado. O esforço despendido deve refletir a criticidade da workload conforme definido pelas prioridades da organização. O agrupamento dos recursos de forma funcional melhora a eficiência (por exemplo, o armazenamento dos bancos de dados de produção, se houver vários bancos de dados). 
+  **Priorizar a lista de componentes: ** priorize a lista de componentes em ordem de esforço. Normalmente, isso é feito por ordem de custos dos componentes, do mais caro para o mais barato, ou da criticidade, conforme definido pelas prioridades da organização.
+ ** Executar a análise:** para cada componente da lista, analise as opções e os serviços disponíveis e escolha a opção mais alinhada com as suas prioridades organizacionais.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Calculadora de Preços](https://calculator.aws/#/) 
+  [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 
+  [Categorias de armazenamento do Amazon S3](https://aws.amazon.com/s3/storage-classes/) 
+  [Produtos da nuvem](https://aws.amazon.com/products/) 

# COST05-BP03 Executar uma análise completa de cada componente
<a name="cost_select_service_thorough_analysis"></a>

 Observe o custo geral de cada componente para a organização. Calcule o custo total de propriedade considerando o custo de operações e gerenciamento, especialmente ao usar serviços gerenciados pelo provedor de nuvem. O esforço de análise deve refletir o benefício potencial (por exemplo, o tempo gasto na análise é proporcional ao custo do componente). 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Considere a economia de tempo que permitirá que sua equipe se concentre na retirada de recursos de endividamento técnico, inovação, agregação de valor e criação do que diferencia os negócios. Por exemplo, talvez você precise mover sem alterações (lift-and-shift) seu ambiente on-premises para a nuvem (também conhecido como redefinir a hospedagem) e otimizar mais tarde. Vale a pena explorar as possíveis economias obtidas com o uso de serviços gerenciados na AWS que removem ou reduzem os custos de licença. Serviços gerenciados na AWS eliminam a sobrecarga operacional e administrativa da manutenção de um serviço, como aplicação de patches ou atualização do sistema operacional, e permitem que você se concentre na inovação e nos negócios. 

 Uma vez que os serviços gerenciados operam em escala da nuvem, eles podem oferecer menor custo por transação ou serviço. Você pode realizar possíveis otimizações para alcançar alguns benefícios tangíveis, sem alterar a arquitetura principal da aplicação. Por exemplo, você pode tentar reduzir o tempo gasto no gerenciamento de instâncias de banco de dados migrando para uma plataforma de banco de dados como serviço, como o [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/), ou migrando sua aplicação para uma plataforma totalmente gerenciada, como o [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/). 

Geralmente, os serviços gerenciados têm atributos que você pode definir para garantir capacidade suficiente. Você deve definir e monitorar esses atributos para que sua capacidade em excesso seja mínima e a performance seja maximizada. Você pode modificar os atributos do AWS Managed Services usando o Console de gerenciamento da AWS ou as APIs e os SDKs da AWS para alinhar as necessidades de recursos com a demanda em constante mudança. Por exemplo, você pode aumentar ou diminuir o número de nós em um cluster do Amazon EMR (ou em um cluster do Amazon Redshift) para aumentar ou reduzir a escala horizontalmente.

Você também pode unir várias instâncias em um recurso da AWS para ativar usos de maior densidade. Por exemplo, você pode provisionar vários bancos de dados pequenos em uma única instância de banco de dados do Amazon Relational Database Service (Amazon RDS). Conforme o uso aumenta, você pode migrar um dos bancos de dados para uma instância de banco de dados Amazon RDS dedicada usando um processo de snapshot e restauração.

Ao provisionar workloads em serviços gerenciados, você deve compreender os requisitos de ajuste da capacidade do serviço. Esses requisitos geralmente são tempo, esforço e qualquer impacto na operação normal da workload. O recurso provisionado deve permitir tempo para que as alterações ocorram, provisionar a sobrecarga necessária para permitir isso. O trabalho contínuo necessário para modificar os serviços pode ser reduzido a praticamente zero usando APIs e SDKs integrados a ferramentas de sistema e monitoramento como o Amazon CloudWatch.

O [Amazon RDS](https://aws.amazon.com/rds/), o [Amazon Redshift](https://aws.amazon.com/redshift/) e o [Amazon ElastiCache](https://aws.amazon.com/elasticache/) fornecem um serviço de banco de dados gerenciado. O [Amazon Athena](https://aws.amazon.com/athena/), o [Amazon EMR](https://aws.amazon.com/emr/) e o [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) fornecem um serviço de análise gerenciado.

[AMS](https://aws.amazon.com/managed-services/) é um serviço que opera a infraestrutura da AWS em nome de clientes e parceiros empresariais. Ele fornece um ambiente seguro e compatível no qual você pode implantar suas workloads. O AMS usa modelos operacionais de nuvem empresarial com automação para permitir que você atenda aos requisitos da sua organização, migre para a nuvem mais rapidamente e reduza seus custos de gerenciamento constantes.

**Etapas da implementação**
+ **Realização de uma análise completa: **usando a lista de componentes, trabalhe com cada componente da maior prioridade para a menor. Para componentes de prioridade maior e mais caros, execute análises adicionais e avalie todas as opções disponíveis e o impacto a longo prazo. Para componentes de prioridade menor, avalie se alterações no uso alterariam a prioridade do componente e, em seguida, execute uma análise de esforço apropriado. 
+  **Comparação de recursos gerenciados e não gerenciados:** considere o custo operacional dos recursos que você gerencia e compare-os com recursos gerenciados pela AWS. Por exemplo, analise seus bancos de dados em execução em instâncias do Amazon EC2 e compare-os com as opções do Amazon RDS (um serviço gerenciado pela AWS) ou do Amazon EMR em comparação com a execução do Apache Spark no Amazon EC2. Ao migrar de uma workload autogerenciada para uma workload totalmente gerenciada pela AWS, pesquise suas opções com cuidado. Os três fatores mais importantes a serem considerados são o [tipo de serviço gerenciado](https://aws.amazon.com/products/?&aws-products-all.q=managed) que você deseja usar, o processo utilizado para [migrar seus dados](https://aws.amazon.com/big-data/datalakes-and-analytics/migrations/) e o entendimento do [modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Total Cost of Ownership (TCO) Calculator](https://aws.amazon.com/tco-calculator/) (Calculadora de custo total de propriedade (TCO) da AWS) 
+  [Categorias de armazenamento do Amazon S3 ](https://aws.amazon.com/s3/storage-classes/) 
+  [Produtos da Nuvem AWS](https://aws.amazon.com/products/) 
+ [Modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/)

 **Vídeos relacionados:** 
+ [ Why move to a managed database? ](https://www.youtube.com/watch?v=VRFdc-MVa4I) (Por que migrar para um banco de dados gerenciado?)
+ [ What is Amazon EMR and how can I use it for processing data? ](https://www.youtube.com/watch?v=jylp2atrZjc) (O que é o Amazon EMR e como usá-lo para processar dados?)

 **Exemplos relacionados:** 
+ [ Why to move to a managed database ](https://aws.amazon.com/getting-started/hands-on/move-to-managed/why-move-to-a-managed-database/) (Por que migrar para um banco de dados gerenciado?)
+ [ Consolidate data from identical SQL Server databases into a single Amazon RDS for SQL Server database using AWS DMS](https://aws.amazon.com/blogs/database/consolidate-data-from-identical-sql-server-databases-into-a-single-amazon-rds-for-sql-server-database-using-aws-dms/) (Consolidar dados de bancos de dados idênticos do Consolidate SQL Server em um banco de dados único do Amazon RDS for SQL Server usando o AWS DMS)
+ [ Deliver data at scale to Amazon Managed Streaming for Apache Kafka (Amazon MSK) ](https://aws.amazon.com/getting-started/hands-on/deliver-data-at-scale-to-amazon-msk-with-iot-core/?ref=gsrchandson) (Entregar dados em grande escala para o Amazon Managed Streaming for Apache Kafka (Amazon MSK))
+ [ Migrate an ASP.NET web application to AWS Elastic Beanstalk](https://aws.amazon.com/getting-started/hands-on/migrate-aspnet-web-application-elastic-beanstalk/?ref=gsrchandson&id=itprohandson) (Migrar uma aplicação Web ASP.NET para o AWS Elastic Beanstalk)

# COST05-BP04 Selecionar software com licenciamento econômico
<a name="cost_select_service_licensing"></a>

 Os softwares de código aberto eliminam os custos de licenciamento de software, o que pode contribuir com custos significativos para as workloads. Quando for necessário um software licenciado, evite licenças vinculadas a atributos arbitrários, como CPUs, e procure aquelas que estejam vinculadas à saída ou aos resultados. O custo dessas licenças é mais próximo do benefício que elas oferecem. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 O código aberto originou-se no contexto do desenvolvimento de software para indicar que o software está em conformidade com determinados critérios de distribuição gratuita. O software de código aberto é composto de código-fonte que pode ser inspecionado, modificado e aprimorado por qualquer pessoa. Com base nos requisitos de negócios, nas habilidades dos engenheiros, no uso previsto ou em outras dependências tecnológicas, as organizações podem considerar o uso de software de código aberto na AWS para minimizar os custos de licença. Ou seja, o custo das licenças de software pode ser reduzido com o uso de [software de código aberto](https://aws.amazon.com/what-is/open-source/). Isso pode ter impacto significativo nos custos da carga de trabalho à medida que o tamanho da carga de trabalho é dimensionado. 

 Avalie os benefícios do software licenciado em relação ao custo total para otimizar a workload. Modele todas as alterações no licenciamento e como elas afetariam seus custos de carga de trabalho. Se um fornecedor alterar o custo da sua licença de banco de dados, investigue como isso afeta a eficiência geral da sua carga de trabalho. Considere anúncios históricos de definição de preço de seus fornecedores para tendências de alterações de licenciamento em seus produtos. Os custos de licenciamento também podem ser dimensionados independentemente do throughput ou do uso, como licenças que escalam por hardware (licenças vinculadas à CPU). Essas licenças devem ser evitadas porque os custos podem aumentar rapidamente sem resultados correspondentes. 

 Por exemplo, operar uma instância do Amazon EC2 na us-east-1 com um sistema operacional Linux permite reduzir os custos em aproximadamente 45%, em comparação com a execução de outra instância do Amazon EC2 no Windows. 

 O [AWS Calculadora de Preços](https://calculator.aws/) oferece uma maneira abrangente de comparar os custos de vários recursos com diferentes opções de licença, como as instâncias do Amazon RDS e diferentes mecanismos de banco de dados. Além disso, o AWS Cost Explorer fornece uma perspectiva inestimável dos custos das workloads existentes, especialmente daquelas que vêm com licenças diferentes. Para gerenciamento de licenças, o [AWS License Manager](https://aws.amazon.com/license-manager) oferece um método simplificado para supervisionamento e gerenciamento de licenças de software. Os clientes podem implantar e operacionalizar o software de código aberto preferido na Nuvem AWS. 

### Etapas da implementação
<a name="implementation-steps"></a>
+ ** Analisar as opções de licença:** analise os termos de licenciamento do software disponível. Procure versões de código aberto que tenham a funcionalidade necessária e veja se os benefícios do software licenciado superam o custo. Termos favoráveis alinham o custo do software aos benefícios que ele oferece.
+ **Analisar o fornecedor do software:** analise todo o histórico de alterações de preços ou de licenciamento do fornecedor. Procure alterações que não estejam alinhadas aos resultados, como termos punitivos para execução em hardware ou plataformas de fornecedores específicos. Além disso, verifique como eles executam auditorias e as penalidades que poderiam ser impostas.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Open Source at AWS](https://aws.amazon.com/opensource/)
+  [Calculadora de custo total de propriedade (TCO) da AWS](https://aws.amazon.com/tco-calculator/) 
+  [Categorias de armazenamento do Amazon S3](https://aws.amazon.com/s3/storage-classes/) 
+  [Produtos da nuvem](https://aws.amazon.com/products/) 

 **Exemplos relacionados:** 
+ [ Blogs de código aberto ](https://aws.amazon.com/blogs/opensource/)
+ [ Blogs de código aberto da AWS](https://aws.github.io/)
+ [Otimização e Avaliação de Licenciamento](https://aws.amazon.com/optimization-and-licensing-assessment/)

# COST05-BP05 Selecionar os componentes desta workload para otimizar o custo alinhado com as prioridades da organização
<a name="cost_select_service_select_for_cost"></a>

 Considere o custo ao selecionar todos os componentes para sua workload. Isso inclui o uso de serviços gerenciados e em nível de aplicação ou arquitetura sem servidor, contêineres ou orientada a eventos a fim de reduzir o custo geral. Minimize os custos de licença usando um software de código aberto ou que não tenha taxas de licença ou alternativas para reduzir os gastos. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Considere o custo de serviços e opções ao selecionar todos os componentes. Isso inclui o uso de serviços gerenciados e em nível de aplicação, como o [Amazon Relational Database Service](https://aws.amazon.com/rds/) (Amazon RDS), [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), o [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS) e o [Amazon Simple Email Service](https://aws.amazon.com/ses/) (Amazon SES) para reduzir o custo geral da organização. 

 Use contêineres e recursos de tecnologia sem servidor para computação, como o [AWS Lambda](https://aws.amazon.com/lambda/) e o [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) para sites estáticos. Se possível, coloque sua aplicação em contêineres e use serviços de contêiner gerenciados pela AWS, como o [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (Amazon ECS) ou [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) (Amazon EKS). 

 Minimize os custos de licença usando software de código aberto ou software sem taxas de licença (por exemplo, Amazon Linux para workloads de computação ou migração de bancos de dados para o Amazon Aurora). 

 você pode usar serviços sem servidor ou em nível de aplicativo, como o [Lambda](https://aws.amazon.com/lambda/), [o Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/), [Amazon SNS](https://aws.amazon.com/sqs/)e o [Amazon SES](https://aws.amazon.com/ses/). Esses serviços eliminam a necessidade de gerenciar um recurso e fornecem a função de execução de código, serviços de enfileiramento e entrega de mensagens. O outro benefício é que eles escalam a performance e o custo de acordo com o uso, permitindo a alocação e a atribuição eficientes de custos. 

 O uso de [arquitetura orientada a eventos](https://aws.amazon.com/what-is/eda/) também é possível com serviços sem servidor. Arquiteturas orientadas a eventos são baseadas em push, então, tudo acontece sob demanda à medida que o evento se apresenta no roteador. Dessa forma, você não paga pela sondagem contínua para conferir um evento. Isso significa um consumo menor de largura de banda de rede, menor utilização de CPU, menor capacidade de frota ociosa e menos handshakes SSL/TLS. 

 Para obter mais informações sobre tecnologia sem servidor, consulte [whitepaper Well-Architected Serverless Application Lens.](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html) 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Selecionar cada serviço para otimizar o custo:** Usando sua análise e lista priorizada, selecione cada opção que fornece a melhor correspondência com suas prioridades organizacionais. Em vez de aumentar a capacidade para atender à demanda, considere outras opções que podem oferecer melhor performance por um custo menor. Por exemplo, se você precisar analisar o tráfego esperado para seus bancos de dados na AWS e pensar em aumentar o tamanho da instância ou usar serviços do Amazon ElastiCache (Redis ou Memcached) a fim de fornecer mecanismos em cache para seus bancos de dados. 
+  **Avaliar a arquitetura orientada a eventos:** O uso de uma arquitetura sem servidor também permite criar uma arquitetura orientada a eventos para aplicações distribuídas e baseadas em microsserviço, o que ajuda a criar soluções escaláveis, resilientes, ágeis e econômicas. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Calculadora de preços da AWS](https://aws.amazon.com/tco-calculator/) 
+  [tecnologia sem servidor da AWS](https://aws.amazon.com/serverless/) 
+  [O que é arquitetura orientada a eventos](https://aws.amazon.com/what-is/eda/) 
+  [Categorias de armazenamento do Amazon S3](https://aws.amazon.com/s3/storage-classes/) 
+  [Produtos da nuvem](https://aws.amazon.com/products/) 
+  [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis) 

 **Exemplos relacionados:** 
+  [Comece a usar a arquitetura orientada a eventos](https://aws.amazon.com/blogs/compute/getting-started-with-event-driven-architecture/) 
+  [Arquitetura orientada a eventos](https://aws.amazon.com/event-driven-architecture/) 
+  [How Statsig runs 100x more cost-effectively using Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/database/how-statsig-runs-100x-more-cost-effectively-using-amazon-elasticache-for-redis/) 
+  [Best practices for working with AWS Lambda functions](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) 

# COST05-BP06 Realizar análises de custos para diferentes usos ao longo do tempo
<a name="cost_select_service_analyze_over_time"></a>

 As workloads podem mudar ao longo do tempo. Alguns serviços ou recursos são mais econômicos em diferentes níveis de uso. Ao executar a análise em cada componente ao longo do tempo e no uso projetado, a workload continua oferecendo um bom custo-benefício ao longo da vida útil. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

À medida que a AWS lança novos serviços e recursos, os serviços ideais para sua workload podem mudar. O esforço necessário deve refletir possíveis benefícios. A frequência da análise da workload depende dos requisitos da sua organização. Se for uma workload com custo significativo, implementar novos serviços mais cedo maximizará a economia de custos, portanto, uma revisão mais frequente poderá ser vantajosa. Outro trigger para revisão é a alteração nos padrões de uso. Alterações significativas no uso podem indicar que serviços alternativos seriam mais ideais.

 Se precisar mover dados para a Nuvem AWS, você poderá selecionar qualquer série de serviços que a AWS oferece e ferramentas de parceiros para ajudar a migrar seus conjuntos de dados, sejam eles arquivos, bancos de dados, imagens de máquina, volumes de bloco ou até backups de fita. Por exemplo, para mover um grande volume de dados para a AWS e dela ou processar dados na borda, você pode usar um dos dispositivos com propósito específico da AWS para mover petabytes de dados offline de forma econômica. Outro exemplo é relativo a taxas de transferência de dados mais altas, um serviço de conexão direta pode ser mais barato do que uma VPN, que fornece a conectividade consistente necessária para sua empresa. 

 Com base na análise de custos para uso diferente no decorrer do tempo, analise sua atividade de escalabilidade. Analise o resultado para ver se a política de escalabilidade pode ser ajustada para adicionar instâncias de vários tipos e opções de compra. Analise suas configurações para verificar se é possível reduzir o mínimo para atender às solicitações do usuário, mas com um tamanho de frota menor e adicionar mais recursos para atender à alta demanda esperada. 

 Realize uma análise de custo para uso diferente no decorrer do tempo conversando com os stakeholders em sua organização e use o recurso de previsão do [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) para prever o possível impacto das alterações de serviço. Monitore os gatilhos de nível de uso utilizando o AWS Budgets, alarmes de faturamento do CloudWatch e o AWS Cost Anomaly Detection para identificar e implementar os serviços mais econômicos com maior rapidez. 

**Etapas da implementação**
+ ** Definição de padrões de uso previstos: **trabalhando com sua organização, como proprietários de produtos e marketing, documente quais serão os padrões de uso previstos e esperados para a workload. Converse com os stakeholders da empresa sobre aumentos de uso e custos históricos e previstos e garanta que os aumentos se alinhem com os requisitos da empresa. Identifique os dias, as semanas ou os meses em que você espera que mais usuários utilizem seus recursos da AWS, o que indica que você deve aumentar a capacidade dos recursos existentes ou adotar serviços adicionais a fim de reduzir o custo e aumentar a performance. 
+ **Realize a análise de custos e uso previsto:** usando os padrões de uso definidos, realize a análise em cada um desses pontos. O esforço de análise deve refletir o resultado provável. Por exemplo, se a alteração no uso for grande, uma análise completa deverá ser realizada para verificar quaisquer custos e alterações. Em outras palavras, quando o custo aumenta, o uso também deve aumentar para a empresa. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Total Cost of Ownership (TCO) Calculator](https://aws.amazon.com/tco-calculator/) (Calculadora de custo total de propriedade (TCO) da AWS) 
+  [Categorias de armazenamento do Amazon S3](https://aws.amazon.com/s3/storage-classes/) 
+  [Produtos da nuvem](https://aws.amazon.com/products/) 
+ [ Amazon EC2 Auto Scaling ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [ Migração de dados para a nuvem ](https://aws.amazon.com/cloud-data-migration/)
+ [AWS Snow Family](https://aws.amazon.com/snow/)

 **Vídeos relacionados:** 
+ [AWS OpsHub for Snow Family](https://www.youtube.com/watch?v=0Q7s7JiBCf0)

# CUSTOS 6. Como atingir as metas de custo ao selecionar tamanho, número e tipo de recurso?
<a name="cost-06"></a>

Escolha o tamanho e o número de recursos apropriados para a tarefa em mãos. Ao selecionar o tipo, tamanho e número mais econômicos, você minimiza o desperdício.

**Topics**
+ [COST06-BP01 Realizar modelagem de custos](cost_type_size_number_resources_cost_modeling.md)
+ [COST06-BP02 Selecionar o tipo, o tamanho e o número do recurso com base nos dados](cost_type_size_number_resources_data.md)
+ [COST06-BP03 Selecionar o tipo, tamanho e número do recurso automaticamente com base nas métricas](cost_type_size_number_resources_metrics.md)

# COST06-BP01 Realizar modelagem de custos
<a name="cost_type_size_number_resources_cost_modeling"></a>

Identifique os requisitos da organização (como as necessidades dos negócios e os compromissos existentes) e realize a modelagem dos custos (custos gerais) da workload e de cada um de seus componentes. Realize atividades de referência para a workload sob diferentes cargas previstas e compare os custos. O esforço de modelagem deve refletir o benefício potencial. Por exemplo, o tempo gasto é proporcional ao custo do componente.

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Execute a modelagem de custos para sua workload e cada um de seus componentes para entender o equilíbrio entre recursos e encontrar o tamanho correto para cada recurso na workload, considerando um nível específico de performance. O entendimento das considerações de custo pode embasar seu processo de tomada de decisão e caso de negócios organizacional ao avaliar os resultados da realização de valor para a implantação planejada da workload. 

 Realize atividades de referência para a workload sob diferentes cargas previstas e compare os custos. O esforço de modelagem deve refletir o benefício potencial. Por exemplo, o tempo gasto é proporcional ao custo do componente ou à economia prevista. Para saber as práticas recomendadas, consulte a [seção Review do Performance Efficiency Pillar of the AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/review.html). 

 Por exemplo, para criar a modelagem de custos para uma workload que consista em recursos de computação, o [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) pode auxiliar com a modelagem de custos para executar workloads. Ele fornece recomendações de dimensionamento correto para recursos de computação com base no uso histórico. Implante os CloudWatch Agents nas instâncias do Amazon EC2 para coletar métricas de memória que ajudam você com recomendações mais precisas no AWS Compute Optimizer. Essa é a fonte de dados ideal para recursos de computação, pois é um serviço gratuito e utiliza Machine Learning para fazer várias recomendações, dependendo dos níveis de risco. 

 Há [vários serviços](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html) que você pode usar com logs personalizados como fontes de dados para dimensionar adequadamente as operações para outros serviços e componentes da workload, como o [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/), o [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) e o [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). O AWS Trusted Advisor confere os recursos e sinaliza os que apresentam baixa utilização, o que pode ajudar você a dimensioná-los corretamente e criar uma modelagem de custo. 

 Veja a seguir as recomendações para dados e métricas de modelagem de custo: 
+  O monitoramento deve refletir com precisão a experiência do usuário. Selecione a granularidade correta para o período e escolha com cuidado o máximo ou o 99º percentil, em vez da média. 
+  Selecione a granularidade correta para o período de análise necessário para cobrir todos os ciclos de workload. Por exemplo, se uma análise de duas semanas for realizada, talvez você esteja deixando passar um ciclo de alta utilização, o que pode levar a subprovisionamento. 
+  Escolha os serviços da AWS certos para sua workload planejada considerando seus compromissos existentes, modelos de preço selecionados para outras workloads e a capacidade de inovar com maior rapidez e concentrar-se em seu valor comercial principal. 

**Etapas da implementação **
+ ** Realização de modelagem de custo para os recursos:** implante a workload ou uma prova de conceito em uma conta separada com os tipos e tamanhos de recursos específicos a serem testados. Execute a workload com os dados de teste e registre os resultados de saída, junto com os dados de custo da hora em que o teste foi executado. Depois, reimplante a workload ou altere os tipos e tamanhos de recursos e execute novamente o teste. Inclua taxas de licença para todos os produtos que você pode usar com esses recursos e custos de operações estimados (mão de obra ou engenharia) para implantar e gerenciar esses recursos ao criar a modelagem de custo. Considere a modelagem de custo para um período (por hora, diária, anual ou três anos).

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+ [ Identifying Opportunities to Right Size ](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html) (Identificar oportunidades para dimensionar o tamanho corretamente )
+  [Amazon CloudWatch features](https://aws.amazon.com/cloudwatch/features/) (Recursos do Amazon CloudWatch) 
+  [Cost Optimization: Amazon EC2 Right Sizing](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html) (Otimização de custos: dimensionamento correto do Amazon EC2) 
+  [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 
+ [AWS Pricing Calculator ](https://calculator.aws/#/) (Calculadora de preços da AWS)

 **Exemplos relacionados:** 
+ [ Perform a Data-Driven Cost Modelling ](https://aws.amazon.com/blogs/mt/how-to-use-aws-well-architected-with-aws-trusted-advisor-to-achieve-data-driven-cost-optimization/) (Executar uma modelagem de custo orientada a dados)
+ [ Estimate the cost of planned AWS resource configurations ](https://aws.amazon.com/premiumsupport/knowledge-center/estimating-aws-resource-costs/) (Estimar o custo das configurações de recursos planejados da AWS)
+ [ Choose the right AWS tools ](https://www.learnaws.org/2019/09/27/choose-right-aws-tools/) (Selecionar as ferramentas certas da AWS)

# COST06-BP02 Selecionar o tipo, o tamanho e o número do recurso com base nos dados
<a name="cost_type_size_number_resources_data"></a>

Selecione o tamanho ou tipo do recurso com base nos dados sobre a workload e nas características do recurso. Por exemplo, computação, memória, throughput ou gravação intensiva. Essa seleção geralmente é feita usando uma versão anterior (on-premises) da workload, a documentação ou outras fontes de informações sobre a workload.

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 O Amazon EC2 fornece uma ampla seleção de tipos de instância com diferentes níveis de capacidade de CPU, memória, armazenamento e rede para atender a diferentes casos de uso. Esses tipos de instância dispõem de diferentes combinações de capacidade de CPU, memória, armazenamento e rede, oferecendo versatilidade ao selecionar a combinação certa de recursos para os projetos. Eles são disponibilizados em vários tamanhos para que seja possível ajustar os recursos com base nas demandas da workload. Para determinar o tipo de instância necessário, reúna os detalhes dos requisitos do sistema da aplicação ou do software a ser executado na instância. Esses detalhes devem incluir: 
+  Sistema operacional 
+  Número de núcleos de CPU 
+  Núcleos de GPU 
+  Quantidade de memória do sistema (RAM) 
+  Tipo e espaço de armazenamento 
+  Requisito de largura de banda da rede 

 Identifique a finalidade dos requisitos de computação e a instância necessária e conheça as várias famílias de instâncias do Amazon EC2. A Amazon oferece as seguintes famílias de tipos de instância: 
+  De uso geral 
+  Otimizadas para computação 
+  Otimizadas para memória 
+  Otimizadas para armazenamento 
+  Computação acelerada 
+  Otimizadas para HPC 

 Para compreender melhor os propósitos e casos de uso específicos aos quais determinada família de instâncias do Amazon EC2 pode atender, consulte [Tipos de instância da AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html). 

 A coleta dos requisitos do sistema é essencial para selecionar a família e o tipo de instância específicos que melhor atendem às suas necessidades. Os nomes dos tipos de instância são compostos do nome da família e do tamanho da instância. Por exemplo, a instância t2.micro é da família T2 e é de tamanho micro. 

 Selecione o tamanho ou o tipo de recurso com base na workload e nas características do recurso (por exemplo, computação, memória, throughput ou gravação intensiva). Essa seleção geralmente é feita usando a modelagem de custos, uma versão anterior da workload (como uma versão on-premises), a documentação ou outras fontes de informações sobre a workload (whitepapers ou soluções publicadas). O uso de calculadoras de preços ou de ferramentas de gerenciamento de custos da AWS pode ajudar a tomar decisões fundamentadas sobre tipos, tamanhos e configurações de instância. 

### Etapas da implementação
<a name="implementation-steps"></a>
+ **Selecionar recursos com base nos dados:** use os dados da modelagem de custos para selecionar o nível de uso previsto da workload e escolher o tipo e o tamanho de recurso especificados. Com base nos dados da modelagem de custos, determine o número de CPUs virtuais, a memória total (GiB), o volume de armazenamento de instâncias local (GB), os volumes do Amazon EBS e o nível de desempenho da rede, levando em consideração a taxa de transferência de dados necessária para a instância. Sempre faça seleções com base em análise detalhada e em dados precisos para otimizar o desempenho e, ao mesmo tempo, gerenciar os custos de forma eficiente.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [Tipos de instância da AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [Amazon CloudWatch features](https://aws.amazon.com/cloudwatch/features/) (Recursos do Amazon CloudWatch) 
+  [Otimização de custos: dimensionamento correto do EC2](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html) 

 **Vídeos relacionados:** 
+ [ Selecting the right Amazon EC2 instance for your workloads ](https://www.youtube.com/watch?v=q5Dn9gcmpJg)
+ [ Right size your service ](https://youtu.be/wcp1inFS78A)

 **Exemplos relacionados:** 
+ [ It just got easier to discover and compare Amazon EC2 instance types ](https://aws.amazon.com/blogs/compute/it-just-got-easier-to-discover-and-compare-ec2-instance-types/)

# COST06-BP03 Selecionar o tipo, tamanho e número do recurso automaticamente com base nas métricas
<a name="cost_type_size_number_resources_metrics"></a>

Use métricas da workload em execução no momento para selecionar o tamanho e o tipo certos para otimizar o custo. Provisione adequadamente o throughput, o dimensionamento e o armazenamento para serviços de computação, armazenamento, dados e rede. Isso pode ser feito com um ciclo de comentários, como escalabilidade automática ou por código personalizado na workload.

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

Crie um loop de comentários dentro da workload que usa métricas ativas da workload em execução para fazer alterações nessa workload. Você pode usar um serviço gerenciado, como [AWS Auto Scaling](https://aws.amazon.com/autoscaling/), que você configura para executar as operações de dimensionamento corretas para você. O AWS também fornece [APIs, SDKs](https://aws.amazon.com/developer/tools/) e funcionalidades que permitem que os recursos sejam modificados com o mínimo de esforço. É possível programar uma workload para interromper e iniciar uma instância do Amazon EC2 para permitir uma alteração de tamanho ou tipo de instância. Isso fornece os benefícios do dimensionamento correto e, ao mesmo tempo, remove quase todo o custo operacional necessário para fazer a alteração.

Alguns serviços do AWS possuem seleção automática de tipo ou tamanho, como [Amazon Simple Storage Service Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/). O Amazon S3 Intelligent-Tiering move automaticamente seus dados entre dois níveis de acesso: acesso frequente e acesso infrequente, com base em seus padrões de uso.

**Etapas da implementação**
+ **Aumentar sua observabilidade configurando métricas de workload:** Capture as principais métricas para a workload. Essas métricas fornecem uma indicação da experiência do cliente, como a saída da workload, e se alinham às diferenças entre tipos e tamanhos de recursos, como uso de CPU e memória. Para recursos de computação, analise os dados de desempenho para dimensionar corretamente suas instâncias do Amazon EC2. Identifique instâncias ociosas e subutilizadas. As principais métricas a serem procuradas são o uso da CPU e a utilização da memória (por exemplo, 40% de utilização da CPU em 90% do tempo, conforme explicado em [Dimensionamento correto com o AWS Compute Optimizer e utilização da memória ativada](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)). Identifique instâncias com uso máximo de CPU e utilização de memória inferior a 40% em um período de quatro semanas. São as instâncias no tamanho certo para reduzir custos. Para recursos de armazenamento, como Amazon S3, você pode usar a [Lente de Armazenamento do Amazon S3](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/), que permite ver 28 métricas em várias categorias no nível do bucket e 14 dias de dados históricos no painel por padrão. Você pode filtrar seu painel da Lente de Armazenamento do Amazon S3 por resumo e otimização de custos ou eventos para analisar métricas específicas. 
+ **Ver recomendações de redimensionamento:** Use as recomendações de dimensionamento correto no AWS Compute Optimizer e a ferramenta de dimensionamento correto do Amazon EC2 no console de gerenciamento de custos ou revise o dimensionamento correto do AWS Trusted Advisor de seus recursos para fazer ajustes em sua workload. É importante usar as [ferramentas certas](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html) ao dimensionar diferentes recursos e seguir as [diretrizes de dimensionamento correto](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html), sejam instâncias do Amazon EC2, classes de armazenamento do AWS ou tipos de instância do Amazon RDS. Para recursos de armazenamento, é possível usar a Lente de Armazenamento do Amazon S3, que oferece visibilidade do uso de armazenamento de objetos e tendências de atividade, bem como faz recomendações acionáveis para otimizar custos e aplicar as práticas recomendadas de proteção de dados. Usando as recomendações contextuais que a [Lente de Armazenamento do Amazon S3](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) obtém da análise de métricas em sua organização, você pode tomar medidas imediatas para otimizar seu armazenamento. 
+ **Selecionar o tipo e o tamanho do recurso automaticamente com base nas métricas:** Usando as métricas de workload, selecione manual ou automaticamente seus recursos de workload. Para recursos de computação, a configuração do AWS Auto Scaling ou a implementação de código dentro da aplicação pode reduzir o esforço necessário se alterações frequentes forem necessárias e, possivelmente, implementar alterações antes de um processo manual. Você pode iniciar e dimensionar automaticamente uma frota de instâncias sob demanda e instâncias spot em um único grupo do Auto Scaling. Além de receber descontos pelo uso de instâncias spot, você pode usar instâncias reservadas ou um Savings Plan para receber taxas com desconto do preço regular da instância sob demanda. Todos esses fatores combinados ajudam você a otimizar sua economia de custos para instâncias do Amazon EC2 e determinar a escala e o desempenho desejados para seu aplicativo. Você também pode usar uma [estratégia de seleção de tipo de instância baseada em atributo (ABS)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) em [Grupos do Auto Scaling (ASG)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html), que permite expressar seus requisitos de instância como um conjunto de atributos, como vCPU, memória e armazenamento. Você pode usar automaticamente os tipos de instância de geração mais recente quando eles são lançados e acessar uma variedade mais ampla de capacidade com instâncias spot do Amazon EC2. A frota do Amazon EC2 e o Amazon EC2 Auto Scaling selecionam e executam instâncias que se ajustam aos atributos especificados, eliminando a necessidade de escolher manualmente os tipos de instância. Para recursos de armazenamento, você pode usar os recursos [Amazon S3 Intelligent Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) e [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/), que permitem selecionar classes de armazenamento automaticamente que oferecem economia automática de custos de armazenamento quando os padrões de acesso aos dados mudam, sem impacto no desempenho ou sobrecarga operacional. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [Dimensionamento correto do AWS](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/) 
+  [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 
+  [Recursos do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) 
+  [Configuração do CloudWatch](https://docs.aws.amazon.com/Amazon/latest/monitoring/GettingSetup.html) 
+  [Publicar métricas personalizadas do CloudWatch](https://docs.aws.amazon.com/Amazon/latest/monitoring/publishingMetrics.html) 
+  [Conceitos básicos do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Lente de Armazenamento do Amazon S3](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) 
+  [Amazon S3 Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/) 
+  [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/) 
+  [Iniciar uma instância do Amazon EC2 usando o SDK](https://docs.aws.amazon.com/sdk-for-net/v2/developer-guide/run-instance.html) 

 **Vídeos relacionados:** 
+  [Dimensionar corretamente seus serviços](https://www.youtube.com/watch?v=wcp1inFS78A) 

 **Exemplos relacionados:** 
+  [Seleção de tipo de instância baseada em atributo do Auto Scaling para a frota do Amazon EC2](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/) 
+  [Otimização do Amazon Elastic Container Service para o custo usando escalabilidade programada ](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/) 
+  [Escalabilidade preditiva com o Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/) 
+  [Otimizar os custos e ganhar visibilidade no uso com a Lente de Armazenamento do Amazon S3](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) 
+  [Laboratórios do Well-Architected: Recomendações de dimensionamento correto (Nível 100)](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/) 
+  [Laboratórios do Well-Architected: Dimensionamento correto com o AWS Compute Optimizer e utilização de memória habilitada (Nível 200)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 

# CUSTOS 7. Como usar os modelos de definição de preço para reduzir custos?
<a name="cost-07"></a>

Use o modelo de definição de preço mais adequado nos recursos para minimizar as despesas.

**Topics**
+ [COST07-BP01 Executar análise de modelo de preço](cost_pricing_model_analysis.md)
+ [COST07-BP02 Escolher regiões com base no custo](cost_pricing_model_region_cost.md)
+ [COST07-BP03 Selecionar contratos de terceiros com termos econômicos](cost_pricing_model_third_party.md)
+ [COST07-BP04 Implementar modelos de preços para todos os componentes dessa workload](cost_pricing_model_implement_models.md)
+ [COST07-BP05 Realizar análise de modelo de preço em nível da conta de gerenciamento](cost_pricing_model_master_analysis.md)

# COST07-BP01 Executar análise de modelo de preço
<a name="cost_pricing_model_analysis"></a>

Analise cada componente da workload. Determine se o componente e os recursos serão executados por períodos estendidos (para descontos de compromisso) ou dinâmicos e curtos (para spot ou sob demanda). Execute uma análise da workload usando as recomendações nas ferramentas de gerenciamento de custos e aplique regras de negócios a essas recomendações para alcançar altos retornos.

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

A AWS tem vários [modelos de preço](https://aws.amazon.com/pricing/) que permitem que você pague pelos seus recursos da maneira mais econômica que atenda às necessidades de sua organização e de acordo com o produto. Trabalhe com suas equipes para determinar o modelo de preço mais apropriado. Com frequência, o modelo de preço consiste em uma combinação de várias opções, tal como determinado por seus requisitos de disponibilidade. 

 As **instâncias sob demanda** permitem que você pague por capacidade computacional ou de banco de dados por hora ou por segundo (60 segundos, no mínimo), dependendo de quais instâncias são executadas, sem compromissos de longo prazo nem pagamentos adiantados. 

 Os **Savings Plans** são um modelo de preço flexível que oferece preços baixos para uso do Amazon EC2, do Lambda e do AWS Fargate, em troca do compromisso com uma quantidade de uso consistente (medida em dólares por hora) por um período de um ou três anos. 

 As **instâncias spot** são um mecanismo de preço do Amazon EC2 que permite que você solicite capacidade computacional extra por uma taxa por hora com desconto (até 90% de desconto no preço sob demanda) sem compromisso inicial. 

 As **instância reservadas** permitem que você obtenha um desconto de até 75% com o pagamento antecipado de capacidade. Para obter mais detalhes, consulte [Otimização de custos por meio de reservas](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html). 

 Você pode optar por incluir um Savings Plans para os recursos associados aos ambientes de produção, qualidade e desenvolvimento. Visto que os recursos da área restrita para testes são fornecidos somente quando necessários, você também pode optar por um modelo sob demanda para os recursos nesse ambiente. Use [instâncias spot](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#spot-instances) da Amazon para reduzir os Amazon EC2 custos ou use [Savings Plans para computação](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#savings-plans) para reduzir o custo do Amazon EC2, do Fargate e do Lambda. A ferramenta de recomendações [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) oferece oportunidades de descontos de compromisso com o Saving Plans. 

 Se alguma vez você já comprou [instâncias reservadas](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/reserved-instances/?track=costop) para o Amazon EC2 ou estabeleceu práticas de alocação de custos em sua organização, poderá continuar usando as instâncias reservadas do Amazon EC2 por enquanto. Entretanto, recomendamos elaborar uma estratégia para usar Savings Plans no futuro como um mecanismo de redução de custos mais flexível. Você pode atualizar as recomendações de Savings Plans (SP) no AWS Cost Management para gerar novas recomendações de Savings Plans sempre que quiser. Use instâncias reservadas (IR) para reduzir os custos do Amazon RDS, do Amazon Redshift, do Amazon ElastiCache e do Amazon OpenSearch Service. Os Saving Plans e as instâncias reservadas estão disponíveis em três opções: pagamento adiantado, pagamento adiantado parcial e sem pagamento adiantado. Use as recomendações de compra de IR e SP fornecidas no AWS Cost Explorer. 

 Para encontrar oportunidades para workloads spot, use uma visualização por hora do uso geral e procure períodos regulares de uso ou elasticidade variáveis. Você pode usar instâncias spot para diversas aplicações tolerantes a falhas e flexíveis. Exemplos incluem servidores Web sem estado, endpoints de API, aplicações de big data e análise, workloads conteinerizadas, CI/CD e outras workloads flexíveis. 

 Analise suas instâncias do Amazon EC2 e do Amazon RDS para ver se elas podem ser desativadas quando não estiverem em uso (após o expediente e nos fins de semana). Essa abordagem permitirá que você reduza os custos em 70% ou mais em comparação a usá-las ininterruptamente. Se você tiver clusters do Amazon Redshift necessários apenas em momentos específicos, poderá pausar o cluster e, posteriormente, retomá-lo. Quando se interrompe o cluster do Amazon Redshift ou a instância do Amazon EC2 e do Amazon RDS, o faturamento de computação é interrompido e somente se aplica a cobrança de armazenamento. 

 Observe que as [reservas de capacidade sob demanda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-pricing-billing.html) (ODCR) não são um desconto de preço. As reservas de capacidade são cobradas pela taxa sob demanda equivalente, quer você execute ou não as instâncias na capacidade reservada. Elas devem ser consideradas quando você precisa fornecer capacidade suficiente para os recursos que pretende executar. As ODCRs não precisam estar atreladas a compromissos de longo prazo, visto que elas podem ser canceladas quando não mais necessárias, mas elas também podem se beneficiar dos descontos que os Savings Plans ou as instâncias reservadas oferecem. 

**Etapas da implementação**
+  **Análise da elasticidade da workload: **usando a granularidade por hora no Cost Explorer ou um painel personalizado, analise a elasticidade da workload. Procure alterações regulares no número de instâncias em execução. As instâncias de curta duração são candidatas a instâncias spot ou frota spot. 
  +  [Laboratório do Well-Architected: Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity) 
  +  [Laboratório do Well-Architected: Visualização de custos](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  **Análise dos contratos de preço existentes:** examine contratos ou compromissos atuais para necessidades de longo prazo. Analise o que você tem no momento e quanto esses compromissos estão em uso. Utilize os descontos contratuais ou contratos empresariais preexistentes. Os [contratos empresariais](https://aws.amazon.com/pricing/enterprise/) oferecem aos clientes a opção de personalizar acordos que melhor atendam às necessidades deles. Com relação a compromissos de longo prazo, considere descontos de preço reservados, instâncias reservadas ou Savings Plans para o tipo específico de instância, a família de instâncias, a Região da AWS e as zonas de disponibilidade. 
+ ** Realização de uma análise de descontos de compromisso:** usando o Cost Explorer em sua conta, examine as recomendações de Savings Plans e instâncias reservadas. Para garantir que você implemente as recomendações corretas com os descontos e riscos necessários, siga os [laboratórios do Well-Architected](https://wellarchitectedlabs.com/cost/costeffectiveresources/). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Accessing Reserved Instance recommendations](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) (Como acessar as recomendações de instâncias reservadas) 
+  [Opções de compra de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+ [AWS Enterprise ](https://aws.amazon.com/pricing/enterprise/)

 **Vídeos relacionados:** 
+  [Economize até 90% e execute workloads de produção no local](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **Exemplos relacionados:** 
+  [Laboratório do Well-Architected: Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity) 
+  [Laboratório do Well-Architected: Visualização de custos](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  [Laboratório do Well-Architected: Modelos de preço](https://wellarchitectedlabs.com/Cost/CostEffectiveResources.html) 

# COST07-BP02 Escolher regiões com base no custo
<a name="cost_pricing_model_region_cost"></a>

A definição de preço dos recursos pode ser diferente em cada região. Identifique as diferenças de custo regionais e implante apenas nas regiões com custos mais altos para atender aos requisitos de latência, residência e soberania de dados. A consideração do custo da região ajuda você a pagar o menor preço geral por essa workload.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

A [infraestrutura da Nuvem AWS](https://aws.amazon.com/about-aws/global-infrastructure/) é global, hospedada em [vários locais em todo o mundo](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)e criada em torno de Regiões da AWS, zonas de disponibilidade, zonas locais, AWS Outposts e zonas do Wavelength. Uma região é um local físico no mundo, e cada região é uma área geográfica separada onde a AWS tem várias zonas de disponibilidade. As zonas de disponibilidade, que são locais isolados em cada região, consistem em um ou mais datacenters discretos, cada um com energia, rede e conectividade redundantes. 

Cada Região da AWS opera de acordo com as condições do mercado local, e a definição de preço dos recursos é diferente em cada região devido às diferenças de custo de terra, fibra, eletricidade e impostos, por exemplo. Escolha uma região específica para operar um componente de sua solução completa para que você possa operar ao menor preço possível globalmente. Use a [Calculadora da AWS](https://calculator.aws/#/) para calcular os custos de sua workload em várias regiões procurando serviços por tipo de local (região, zona do Wavelength e zona local) e região. 

Ao projetar suas soluções, uma prática recomendada é buscar colocar os recursos de computação mais perto dos usuários para proporcionar menor latência e forte soberania de dados. Selecione a localização geográfica com base nos requisitos de segurança, performance, privacidade de dados e empresariais. Para aplicações com usuários finais globais, use várias localidades.

 Use regiões que ofereçam preços mais baixos por serviços da AWS para implantar suas workloads se você não tiver obrigações em requisitos de privacidade de dados, segurança e empresariais. Por exemplo, se sua região padrão for ap-southeasth-2 (Sydney) e não houver restrições (privacidade de dados, segurança, por exemplo) quanto ao uso de outras regiões, a implantação de instâncias não essenciais (desenvolvimento e teste) Amazon EC2 na região north-east-1 (N. da Virgínia) custará menos. 

![\[Grafo mostrando diferentes regiões com conformidade, latência, custo, serviços e recursos.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/region-feature-matrix.png)


 

 A tabela de matriz anterior mostra que a região 4 é a melhor opção para esse determinado cenário porque a latência é baixa em comparação a outras regiões, o serviço está disponível e é a região mais barata. 

## Etapas da implementação
<a name="implementation-steps"></a>
+ ** Revise a definição de preço da Região da AWS: **Analise os custos da workload na região atual. Começando com os custos maiores por serviço e tipo de uso, calcule os custos em outras regiões que estão disponíveis. Se a economia prevista ultrapassar o custo de mover o componente ou a workload, migre para a nova região. 
+  **Analise os requisitos para implantações em várias regiões:** analise seus requisitos e obrigações empresariais (privacidade de dados, segurança ou performance) para descobrir se há restrições quanto ao uso de vários regiões. Se não houver obrigações que restrinjam você ao uso de uma região, use várias regiões. 
+  **Analise a transferência de dados necessária:** Leve em conta os custos de transferência de dados ao selecionar regiões. Mantenha seus dados perto de seu cliente e dos recursos. Selecione Regiões da AWS mais baratas onde os dados fluam e haja transferência de dados mínima. Dependendo dos requisitos empresariais para transferência de dados, você pode usar [Amazon CloudFront](https://aws.amazon.com/cloudfront/), o [AWS PrivateLink](https://aws.amazon.com/privatelink/), o [AWS Direct Connect](https://aws.amazon.com/directconnect/)e o [AWS Virtual Private Network](https://aws.amazon.com/vpn/) para reduzir seus custos de rede, melhorar a performance e aprimorar a segurança. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Acesso a recomendações de instância reservada](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [Definição de preço do Amazon EC2](https://aws.amazon.com/ec2/pricing/) 
+  [Opções de compra de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+  [Region Table (Tabela de regiões)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) 

 **Vídeos relacionados:** 
+  [Economize até 90% e execute cargas de trabalho de produção no local](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **Exemplos relacionados:** 
+ [ Overview of Data Transfer Costs for Common Architectures (Visão geral dos custos de transferência de dados para arquiteturas comuns) ](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [ Cost Considerations for Global Deployments (Considerações de custo para implantações globais) ](https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-considerations-for-global-deployments/)
+ [ O que considerar ao selecionar uma região para suas workloads ](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
+ [ Well-Architected Labs: Restrict service usage by Region (Level 200) (Well-Architected Labs: uso restrito do serviço por região (nível 200)) ](https://www.wellarchitectedlabs.com/cost/200_labs/200_2_cost_and_usage_governance/2_ec2_restrict_region/)

# COST07-BP03 Selecionar contratos de terceiros com termos econômicos
<a name="cost_pricing_model_third_party"></a>

 Acordos e termos econômicos garantem que o custo desses serviços seja dimensionado de acordo com os benefícios oferecidos. Selecione contratos e definição de preço que escalem quando oferecerem benefícios adicionais à sua organização. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Existem vários produtos no mercado que podem ajudar você a gerenciar os custos em ambientes de nuvem. Eles podem ter algumas diferenças em termos de recursos que dependem dos requisitos do cliente, como alguns que enfatizam a governança ou a visibilidade dos custos e outros a otimização de custos. Um fator-chave para a eficácia da otimização e da governança de custos é usar a ferramenta certa com os recursos necessários e o modelo de preços correto. Esses produtos têm modelos de preços diferentes. Alguns aplicam determinada porcentagem de cobrança sobre sua fatura mensal, enquanto outros aplicam uma porcentagem sobre as economias obtidas. O ideal é pagar apenas pelo que você precisa. 

 Ao usar soluções ou serviços de terceiros na nuvem, é importante que as estruturas de preços estejam alinhadas aos resultados desejados. A definição de preço deve ser dimensionada de acordo com os resultados e o valor que fornece. Por exemplo, em software que leva uma porcentagem das economias que ele fornece, quanto mais você economiza (resultado), mais ele cobra. Os contratos de licença em que você paga mais conforme suas despesas aumentam nem sempre podem ser vantajosos em termos de otimização de custos. No entanto, se o fornecedor oferecer benefícios claros para todos os componentes da sua fatura, talvez essa taxa de ajuste de escala seja aceitável. 

 Por exemplo, uma solução que fornece recomendações para o Amazon EC2 e que aplica uma porcentagem de cobrança sobre toda a fatura poderá se tornar mais cara se você usar outros serviços que não oferecem nenhum benefício. Outro exemplo é um serviço gerenciado que é cobrado segundo uma porcentagem do custo dos recursos gerenciados. O tamanho maior de uma instância pode não exigir necessariamente maior esforço de gerenciamento, mas pode ter uma cobrança maior. Verifique se essas disposições de definição de preços de serviços incluem um programa ou recursos de otimização de custos no respectivo serviço para promover a eficiência. 

 Os clientes podem encontrar produtos mais avançados ou mais fáceis de usar no mercado. Você precisa considerar o custo desses produtos e avaliar possíveis resultados da otimização de custos a longo prazo. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  ** Analisar contratos e termos de terceiros: ** analise os preços em contratos com terceiros. Execute modelagem para diferentes níveis de uso e leve em consideração novos custos, como o uso de novos serviços ou aumentos nos serviços atuais, devido ao crescimento da workload. Decida se os custos adicionais fornecem os benefícios necessários para a sua empresa. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Accessing Reserved Instance recommendations](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) (Como acessar as recomendações de instâncias reservadas) 
+  [Opções de compra de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 

 **Vídeos relacionados:** 
+  [Economize até 90% e execute workloads de produção no local](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

# COST07-BP04 Implementar modelos de preços para todos os componentes dessa workload
<a name="cost_pricing_model_implement_models"></a>

 Os recursos em execução permanente devem utilizar capacidade reservada, como Savings Plans ou instâncias reservadas. A capacidade de curto prazo está configurada para usar instâncias spot ou frota spot. As instâncias sob demanda são usadas somente para workloads de curto prazo que não podem ser interrompidas e não são executadas por tempo suficiente para a capacidade reservada, entre 25% e 75% do período, dependendo do tipo do recurso. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Para melhorar o custo-benefício, a AWS fornece várias recomendações de compromisso com base no uso anterior. Essas recomendações podem ser usadas para compreender o que você pode economizar e como o compromisso será usado. É possível usar esses serviços como instâncias sob demanda ou spot ou assumir um compromisso por determinado período e reduzir os custos sob demanda com instâncias reservadas (RIs) e Savings Plans (SPs). É necessário compreender, além de cada componente da workload e dos vários serviços da AWS, os descontos de compromisso, as opções de compra e as instâncias spot desses serviços para otimizar a workload. 

 Considere os requisitos dos componentes da workload e informe-se sobre os diferentes modelos de preços desses serviços. Defina o requisito de disponibilidade desses componentes. Determine se há vários recursos independentes que executam a função na carga de trabalho e quais são os requisitos da carga de trabalho ao longo do tempo. Compare o custo dos recursos usando o modelo de definição de preço sob demanda padrão e outros modelos aplicáveis. Leve em consideração possíveis alterações nos recursos ou componentes da carga de trabalho. 

 Por exemplo, vamos analisar essa arquitetura de aplicações web na AWS. Esse exemplo de workload consiste em vários serviços da AWS, como o Amazon Route 53, o AWS WAF, o Amazon CloudFront, as instâncias do Amazon EC2, as instâncias do Amazon RDS, os balanceadores de carga, o armazenamento do Amazon S3 e o Amazon Elastic File System (Amazon EFS). Você precisa analisar cada um desses serviços e identificar as possíveis oportunidades de redução de custos com diferentes modelos de preços. Alguns deles podem ser elegíveis para IRs ou SPs, e outros podem estar disponíveis apenas sob demanda. Como mostrado na imagem a seguir, alguns dos serviços da AWS podem ser compromissados usando IRs ou SPs. 

![\[Chart of AWS services committed using Reserved Instances and Savings Plans\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/ri-sp-services.png)


### Etapas da implementação
<a name="implementation-steps"></a>
+  **Implementar modelos de preços: ** usando os resultados da análise, compre Savings Plans, instâncias reservadas ou implemente instâncias spot. Se esta for a sua primeira compra de compromisso, escolha as cinco ou dez principais recomendações da lista, monitore e analise os resultados de um ou dos dois próximos meses. O AWS Cost Management Console fornece orientações durante o processo. Analise as recomendações de IR ou de SP no console, personalize as recomendações (tipo, pagamento e prazo) e analise o compromisso por hora (por exemplo, USD 20 por hora) e adicione ao carrinho. Os descontos se aplicam automaticamente ao uso qualificado. Compre uma pequena quantidade de descontos de compromisso em ciclos regulares (por exemplo, a cada duas semanas ou mensalmente). Implemente instâncias spot para workloads que podem ser interrompidas ou que são sem estado. Por fim, selecione instâncias sob demanda do Amazon EC2 e aloque recursos para os demais requisitos.
+  **Ciclo de análise da workload:** implemente um ciclo de análise da workload que examine especificamente a cobertura do modelo de preços. Assim que a workload tiver a cobertura necessária, compre descontos de compromisso adicionais parcialmente (a cada dois meses) ou conforme o uso da sua organização mudar.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Understanding your Savings Plans recommendations ](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+  [Acesso a recomendações de instância reservada](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [Como comprar instâncias reservadas](https://aws.amazon.com/ec2/pricing/reserved-instances/buyer/) 
+  [Opções de compra de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+  [Instâncias spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) 
+ [ Modelos de reserva para outros serviços da AWS](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-reservation-models/reservation-models-for-other-aws-services.html)
+ [ Savings Plans Supported Services ](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-services.html)

 **Vídeos relacionados:** 
+  [Economize até 90% e execute workloads de produção no local](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **Exemplos relacionados:** 
+ [ What should you consider before purchasing Savings Plans? ](https://repost.aws/knowledge-center/savings-plans-considerations)
+ [ How can I use Cost Explorer to analyze my spending and usage? ](https://repost.aws/knowledge-center/cost-explorer-analyze-spending-and-usage)

# COST07-BP05 Realizar análise de modelo de preço em nível da conta de gerenciamento
<a name="cost_pricing_model_master_analysis"></a>

 Confira as ferramentas de gerenciamento de faturamento e de custos e veja os descontos recomendados com compromissos e reservas para realizar uma análise regular no nível da conta de gerenciamento. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A execução de uma modelagem de custo regular ajuda você a implementar oportunidades de otimização em várias workloads. Por exemplo, se várias workloads usarem instâncias sob demanda, em um nível agregado, o risco de alteração será menor e a implementação de um desconto baseado em compromisso poderá atingir um custo geral mais baixo. É recomendável realizar análises em ciclos regulares de duas semanas a um mês. Isso permite que você faça pequenas compras de ajuste, para que a cobertura de seus modelos de preço continue a evoluir com suas workloads dinâmicas e os respectivos componentes. 

 Use a ferramenta de recomendações do [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) para encontrar oportunidades de descontos de compromisso em sua conta de gerenciamento. As recomendações em nível de conta de gerenciamento são calculadas considerando-se o uso em todas as contas da organização da AWS que têm instâncias reservadas (RI) ou Savings Plans (SP). Elas também são calculadas quando o compartilhamento de descontos é ativado para recomendar um compromisso que maximize a economia em todas as contas. 

 Embora a compra em nível da conta de gerenciamento seja otimizada para obter o máximo de economia em muitos casos, pode haver situações em que você considere comprar SPs em nível da conta vinculada, como quando você deseja que os descontos se apliquem primeiro ao uso nessa conta vinculada específica. As recomendações da conta principal são calculadas em nível de conta individual para maximizar as economias em cada conta isolada. Se sua conta tiver compromissos de RI e SP, eles serão aplicados na seguinte ordem: 

1.  RI de zona 

1.  RI padrão 

1.  RI conversível 

1.  Plano de economia de instâncias 

1.  Plano de economia de computação 

 Se você comprar um SP em nível da conta de gerenciamento, a economia será aplicada com base na porcentagem de desconto mais alta para a mais baixa. Os SPs em nível da conta de gerenciamento examinam todas as contas vinculadas e aplicarão as economias sempre que o desconto for maior. Se desejar restringir onde as economias são aplicadas, você pode comprar um Savings Plan em nível da conta vinculada e, sempre que a conta estiver executando serviços computacionais qualificados, o desconto será aplicado primeiro. Quando a conta não estiver executando serviços computacionais qualificados, o desconto será compartilhado entre as outras contas vinculadas na mesma conta de gerenciamento. O compartilhamento de descontos está ativado por padrão, mas pode ser desativado se necessário. 

 Em uma família de faturamento consolidado, os Savings Plans são aplicados primeiro ao uso da conta do proprietário e depois ao uso de outras contas. Isso ocorrerá somente se você tiver o compartilhamento habilitado. Seus Savings Plans são aplicados primeiro à sua maior porcentagem de economia. Se houver vários usos com porcentagens de economia iguais, Savings Plans serão aplicados ao primeiro uso com a taxa mais baixa de Savings Plans. Os Savings Plans continuam a ser aplicados até que não haja mais usos restantes ou que seu compromisso seja esgotado. Qualquer uso restante é cobrado de acordo com as tarifas sob demanda. É possível atualizar as recomendações de Savings Plans no Gerenciamento de Custos da AWS para gerar novas recomendações de Savings Plans a qualquer momento. 

 Depois de analisar a flexibilidade das instâncias, você pode confirmar seguindo as recomendações. Crie uma modelagem de custos analisando os custos de curto prazo da workload com possíveis opções de recursos diferentes, analisando os modelos de preço da AWS e alinhando-os aos requisitos empresariais para encontrar o custo total de propriedade e [otimização dos custos](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html) de custos. 

### Etapas da implementação
<a name="implementation-steps"></a>

 **Executar uma análise de desconto de compromisso**: use o Cost Explorer na conta, analise as recomendações de instâncias reservadas e Savings Plans. Entenda as recomendações de Savings Plans e estime seus gastos mensais e as economias mensais. Examine as recomendações no nível da conta de gerenciamento, que são calculadas considerando o uso em todas as contas em sua organização da AWS que têm o compartilhamento de descontos de RI ou Savings Plans habilitado, com o intuito de ter o máximo de economia nas contas. Você pode verificar se implementou as recomendações corretas com os descontos e riscos necessários seguindo os laboratórios do Well-Architected. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Como a definição de preço da AWS funciona?](https://aws.amazon.com/pricing/?nc2=h_ql_pr_ln) 
+  [Opções de compra de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+  [Visão geral dos Savings Plans](file:///Users/mergenf/Documents/WELL%20ARCHITECTED/COST%20OPT%20PILLAR/phase3a/COST06/•%09https:/docs.aws.amazon.com/savingsplans/latest/userguide/sp-overview.html) 
+  [Recomendações de Savings Plans](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html) 
+  [Acesso a recomendações de instância reservada](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [Conceitos básicos sobre a recomendação de Savings Plans](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html) 
+  [Como os Savings Plans se aplicam ao uso da AWS](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html) 
+  [Saving Plans com faturamento consolidado](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-consolidated-billing/) 
+  [Ativação de instâncias reservadas compartilhadas e descontos de Savings Plans](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html) 

 **Vídeos relacionados:** 
+  [Economize até 90% e execute cargas de trabalho de produção no local](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **Exemplos relacionados:** 
+  [AWS Well-Architected Lab: Pricing Models (Level 200)](https://wellarchitectedlabs.com/cost/200_labs/200_3_pricing_models/) 
+  [AWS Well-Architected Labs: Pricing Model Analysis (Level 200)](https://www.wellarchitectedlabs.com/cost/200_labs/200_pricing_model_analysis/) 
+  [O que devo considerar antes de comprar um Savings Plan?](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-considerations/) 
+  [How can I use rolling Savings Plans to reduce commitment risk?](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-can-i-use-rolling-savings-plans-to-reduce-commitment-risk/) 
+  [Quando uso instâncias spot](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-leveraging-ec2-spot-instances/when-to-use-spot-instances.html) 

# CUSTOS 8. Como planejar as cobranças de transferência de dados?
<a name="cost-08"></a>

Planeje e monitore as cobranças de transferência de dados para tomar decisões de arquitetura que minimizam custos. Uma mudança arquitetônica pequena, porém eficaz, pode reduzir drasticamente os custos operacionais ao longo do tempo. 

**Topics**
+ [COST08-BP01 Executar a modelagem de transferência de dados](cost_data_transfer_modeling.md)
+ [COST08-BP02 Selecionar os componentes para otimizar o custo da transferência de dados](cost_data_transfer_optimized_components.md)
+ [COST08-BP03 Implantar serviços para reduzir custos de transferência de dados](cost_data_transfer_implement_services.md)

# COST08-BP01 Executar a modelagem de transferência de dados
<a name="cost_data_transfer_modeling"></a>

 Reúna os requisitos da organização e execute a modelagem de transferência de dados da carga de trabalho e de cada um dos componentes. Isso identifica o menor ponto de custo para os requisitos atuais de transferência de dados. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Ao projetar uma solução na nuvem, as taxas de transferência de dados geralmente são negligenciadas devido ao hábito de projetar a arquitetura usando datacenters on-premises ou à falta de conhecimento. As taxas de transferência de dados na AWS são determinadas pela origem, pelo destino e pelo volume do tráfego. A consideração dessas taxas durante a fase de projeto pode resultar em redução de custos. É muito importante compreender onde ocorre a transferência de dados na workload, o custo da transferência e os respectivos benefícios associados para estimar com precisão o custo total de propriedade (TCO). Isso permite que você tome uma decisão embasada para modificar ou aceitar a decisão arquitetônica. Por exemplo, você pode ter uma configuração de várias zonas de disponibilidade na qual você replica dados entre as zonas de disponibilidade. 

 Você modela os componentes dos serviços que transferem os dados na workload e conclui que esse é um custo aceitável (de modo semelhante ao pagamento por computação e armazenamento nas duas zonas de disponibilidade) para alcançar a confiabilidade e a resiliência necessárias. Modele os custos em diferentes níveis de uso. O uso da carga de trabalho pode mudar ao longo do tempo, e diferentes serviços podem ser mais econômicos em diferentes níveis. 

 Ao modelar a transferência de dados, considere a quantidade de dados ingeridos e a origem desses dados. Além disso, considere a quantidade de dados processados e a quantidade de armazenamento ou capacidade computacional necessária. Durante a modelagem, siga as práticas recomendadas de rede para sua arquitetura de workload a fim de otimizar os possíveis custos de transferência de dados. 

 O AWS Calculadora de Preços pode ajudar você a ver os custos estimados de serviços específicos da AWS e da transferência de dados esperada. Se você já tiver uma workload em execução (para fins de teste ou em um ambiente de pré-produção), use o [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) ou o [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) (CUR) para compreender e modelar os custos de transferência de dados. Configure uma prova de conceito (PoC) ou teste sua carga de trabalho e execute um teste com uma carga simulada realista. Você pode modelar seus custos em diferentes demandas de carga de trabalho. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Identificar os requisitos:** qual é a principal meta e os requisitos de negócios para a transferência de dados planejada entre a origem e o destino? Quais são os resultados obtidos no final? Reúna os requisitos de negócios e defina o resultado esperado. 
+  **Identificar a origem e o destino:** qual é a fonte de dados e o destino da transferência de dados; por exemplo, dentro das Regiões da AWS, para os serviços da AWS ou para a internet? 
  + [ Data transfer within an Região da AWS](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-within-region)
  + [ Data transfer between Regiões da AWS](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-between-regions)
  + [ Data transfer out to the internet ](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-out-internet)
+  **Identificar as classificações dos dados:** qual é a classificação dos dados para essa transferência de dados? De que tipo são esses dados? Qual é o tamanho dos dados? Com que frequência os dados devem ser transferidos? Os dados são sigilosos? 
+  **Identificar as ferramentas ou os serviços da AWS a serem usados:** quais serviços da AWS são usados para essa transferência de dados? É possível usar um serviço já provisionado para outra workload? 
+  **Calcular os custos da transferência de dados: **use os [Preços da AWS](https://aws.amazon.com/pricing/) e a modelagem de transferência de dados que você criou anteriormente para calcular os custos da transferência de dados para a workload. Calcule os custos da transferência de dados em diferentes níveis de uso, tanto para aumentos quanto para reduções no uso da workload. Quando houver várias opções para a arquitetura da workload, calcule o custo de cada uma delas a título de comparação. 
+  ** Vincular os custos aos resultados:** para cada custo de transferência de dados incorrido, especifique o resultado obtido pela workload. Se a transferência for entre componentes, poderá ser para desacoplamento; se for entre zonas de disponibilidade, poderá ser para redundância. 
+  **Criar modelagem de transferência de dados:** depois de coletar todas as informações, crie uma modelagem de transferência de dados de base conceitual para vários casos de uso e diferentes workloads. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Soluções de armazenamento em cache da AWS](https://aws.amazon.com/caching/aws-caching/) 
+  [Preços da AWS](https://aws.amazon.com/pricing/) 
+  [Preços do Amazon EC2](https://aws.amazon.com/ec2/pricing/on-demand/) 
+  [Preços da Amazon VPC](https://aws.amazon.com/vpc/pricing/) 
+ [ Understanding data transfer charges ](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html)

 **Vídeos relacionados:** 
+ [Monitoramento e otimização dos custos de transferência de dados](https://www.youtube.com/watch?v=UjliYz25_qo)
+ [ Introduction to Amazon S3 Transfer Acceleration ](https://youtu.be/J2CVnmUWSi4)

 **Exemplos relacionados:** 
+ [ Overview of Data Transfer Costs for Common Architectures ](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/) (Visão geral dos custos de transferência de dados para arquiteturas comuns)
+ [AWS Prescriptive Guidance for Networking ](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortDate&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23network&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all)

# COST08-BP02 Selecionar os componentes para otimizar o custo da transferência de dados
<a name="cost_data_transfer_optimized_components"></a>

 Todos os componentes são selecionados, e a arquitetura é projetada para reduzir os custos de transferência de dados. Isso inclui o uso de componentes como otimização de rede de longa distância (WAN) e configurações de várias zonas de disponibilidade (AZ). 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 A arquitetura da transferência de dados minimiza os custos da transferência de dados. Isso pode envolver o uso de redes de entrega de conteúdo para localizar os dados mais perto dos usuários ou o uso de links de rede dedicados do ambiente on-premises para a AWS. Você também pode usar a otimização de WAN e a otimização de aplicações para reduzir a quantidade de dados transferidos entre componentes. 

 Ao transferir dados para a Nuvem AWS ou dentro dela, é essencial conhecer o destino com base em diversos casos de uso, a natureza dos dados e os recursos de rede disponíveis para selecionar os serviços certos da AWS e otimizar a transferência de dados. A AWS oferece uma variedade de serviços de transferência de dados personalizados para diversos requisitos de migração de dados. Selecione as opções corretas de [armazenamento de dados](https://aws.amazon.com/products/storage/) e de [transferência de dados](https://aws.amazon.com/cloud-data-migration/) com base nas necessidades empresariais da organização. 

 Ao planejar ou analisar a arquitetura da workload, considere o seguinte: 
+  **Usar os endpoints da VPC na AWS:** os endpoints da VPC permitem conexões privadas entre a VPC e os serviços da AWS compatíveis. Isso permite evitar o uso da internet pública, o que pode resultar em custos de transferência de dados. 
+  **Usar um gateway NAT:** use um [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) para que as instâncias em uma sub-rede privada possam se conectar à internet ou aos serviços fora da VPC. Verifique se os recursos por trás do gateway NAT que enviam mais tráfego estão na mesma zona de disponibilidade do gateway NAT. Caso contrário, crie novos gateways NAT na mesma zona de disponibilidade do recurso para reduzir as taxas de transferência de dados entre AZs. 
+  **Usar o AWS Direct Connect**: o Direct Connect ignora a internet pública e estabelece uma conexão direta e privada entre a rede on-premises e a AWS. Isso pode ser mais econômico e consistente do que transferir grandes volumes de dados pela internet. 
+  **Evitar transferir dados entre limites regionais:** as transferências de dados entre Regiões da AWS (de uma região para outra) normalmente geram cobranças. A decisão de seguir um caminho multirregional deve ser muito cuidadosa. Para obter mais detalhes, consulte [Cenários de várias regiões](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/multi-region-scenarios.html). 
+  **Monitorar a transferência de dados:** use o Amazon CloudWatch e os [logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) para capturar detalhes sobre a transferência de dados e o uso da rede. Analise as informações de tráfego de rede capturadas nas VPCs, como o endereço IP ou o intervalo de entrada e saída das interfaces de rede. 
+  **Analisar o uso da rede:** use ferramentas de medição e de geração de relatórios, como os painéis de CUDOS do AWS Cost Explorer ou o CloudWatch, para compreender o custo da transferência de dados da workload. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Selecionar os componentes da transferência de dados:** usando a modelagem de transferência de dados explicada em [COST08-BP01 Executar a modelagem de transferência de dados](cost_data_transfer_modeling.md), concentre-se em quais são os maiores custos da transferência de dados ou em quais seriam se o uso da workload mudasse. Procure arquiteturas alternativas ou componentes adicionais que removam ou reduzam a necessidade da transferência de dados (ou que diminuam o custo). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [COST08-BP01 Executar a modelagem de transferência de dados](cost_data_transfer_modeling.md) 
+  [COST08-BP03 Implantar serviços para reduzir custos de transferência de dados](cost_data_transfer_implement_services.md) 

 **Documentos relacionados:** 
+ [ Migração de dados para a nuvem ](https://aws.amazon.com/cloud-data-migration/)
+  [Soluções de armazenamento em cache da AWS](https://aws.amazon.com/caching/aws-caching/) 
+  [Deliver content faster with Amazon CloudFront](https://aws.amazon.com/getting-started/tutorials/deliver-content-faster/) 

 **Exemplos relacionados:** 
+ [ Overview of Data Transfer Costs for Common Architectures ](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/) (Visão geral dos custos de transferência de dados para arquiteturas comuns)
+ [AWS Network Optimization Tips ](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [ Optimize performance and reduce costs for network analytics with VPC Flow Logs in Apache Parquet format ](https://aws.amazon.com/blogs/big-data/optimize-performance-and-reduce-costs-for-network-analytics-with-vpc-flow-logs-in-apache-parquet-format/)(Otimize o desempenho e reduza os custos de análise da rede com os logs de fluxo da VPC no formato Apache Parquet)

# COST08-BP03 Implantar serviços para reduzir custos de transferência de dados
<a name="cost_data_transfer_implement_services"></a>

 Implemente serviços para reduzir a transferência de dados. Por exemplo, é possível usar locais da borda ou redes de entrega de conteúdo (CDN) para fornecer conteúdo aos usuários finais, criar camadas de cache na frente de servidores de aplicações ou bancos de dados e usar conexões de rede dedicadas em vez de VPN para conectividade com a nuvem. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Existem vários serviços da AWS que podem ajudar a otimizar o uso da transferência de dados pela rede. Dependendo da arquitetura da nuvem e dos componentes e tipo da workload, esses serviços podem ajudar na compactação, no armazenamento em cache e no compartilhamento e na distribuição do tráfego na nuvem. 
+  [Amazon CloudFront](https://aws.amazon.com/cloudfront/) é uma rede de entrega de conteúdo global que entrega dados com baixa latência e altas velocidades de transferência. Ele armazena dados em cache em pontos de presença no mundo inteiro, o que reduz a carga sobre seus recursos. Ao usar o CloudFront, você pode reduzir o trabalho administrativo para entregar conteúdo a um grande número de usuários globalmente com latência mínima. O [pacote security savings](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/?sc_channel=em&sc_campaign=Launch_mult_OT_awsroadmapemail_20200910&sc_medium=em_whats_new&sc_content=launch_ot_ot&sc_country=mult&sc_geo=mult&sc_category=mult&sc_outcome=launch) pode ajudar você a economizar até 30% do uso do CloudFront se você planeja aumentar o uso ao longo do tempo. 
+  [AWS Direct Connect](https://aws.amazon.com/directconnect/) permite estabelecer uma conexão de rede dedicada com a AWS. Isso pode reduzir os custos de rede, aumentar a largura de banda e fornecer uma experiência de rede mais consistente do que conexões baseadas em Internet. 
+  [Site-to-Site VPN](https://aws.amazon.com/vpn/) permite estabelecer uma conexão segura e privada entre a rede privada e a rede global da AWS. Ele é ideal para pequenos escritórios ou parceiros de negócios porque oferece conectividade simplificada, além de ser um serviço totalmente gerenciado e elástico. 
+  [Endpoints da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) permitem conectividade entre os serviços da AWS em redes privadas e podem ser usados para reduzir os custos de transferência de dados pública e [Gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) NAT. [VPC endpoints de gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-gateway.html) não tem cobranças por hora e oferecem suporte ao Amazon S3 e ao Amazon DynamoDB. [VPC endpoints de interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) são fornecidos pelo [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) e têm uma taxa horária e por GB de custo para uso. 
+  [gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) fornecem escalabilidade e gerenciamento integrados, reduzindo os custos, em comparação com uma instância NAT independente. Coloque os gateways NAT nas mesmas zonas de disponibilidade das instâncias de alto tráfego e pense no uso de endpoints da VPC para as instâncias que precisam acessar o Amazon DynamoDB ou o Amazon S3 a fim de reduzir os custos de transferência e processamento de dados. 
+  Use [AWS Snow Family](https://aws.amazon.com/snow/) dispositivos que têm recursos de computação para coletar e processar dados na borda. Os dispositivos da AWS Snow Family ([Snowball Edge](https://aws.amazon.com/snowcone/), o [Snowball Edge](https://aws.amazon.com/snowball/) e [Snowmobile](https://aws.amazon.com/snowmobile/)) permitem que você mova petabytes de dados para o ambiente econômico e off-line da Nuvem AWS. 

### Etapas da implementação
<a name="implementation-steps"></a>
+  **Implementar serviços:** Selecione os serviços de rede aplicáveis da AWS com base no serviço e no tipo de workload usando a modelagem de transferência de dados e revisando os logs de fluxo da VPC. Veja onde estão os maiores custos e os maiores fluxos de volume. Analise os serviços da AWS e avalie se algum deles reduz ou remove a transferência, especificamente a entrega de conteúdo e as redes. Procure também serviços de armazenamento em cache em que haja acesso repetido aos dados ou grandes quantidades de dados. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Direct Connect](https://aws.amazon.com/directconnect/) 
+  [AWS Explore Our Products](https://aws.amazon.com/) 
+  [AWS caching solutions](https://aws.amazon.com/caching/aws-caching/) 
+  [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 
+  [AWS Snow Family](https://aws.amazon.com/snow/) 
+  [Pacote Amazon CloudFront Security Savings](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/) 

 **Vídeos relacionados:** 
+  [Monitoramento e otimização dos custos de transferência de dados](https://www.youtube.com/watch?v=UjliYz25_qo) 
+  [Série de otimização de custos da AWS: CloudFront](https://www.youtube.com/watch?v=k8De2AfAN3k) 
+  [Como posso reduzir as taxas de transferência de dados do meu gateway NAT?](https://www.youtube.com/watch?v=hq4KtPRezus) 

 **Exemplos relacionados:** 
+  [How-to chargeback shared services: An AWS Transit Gateway example](https://aws.amazon.com/blogs/aws-cloud-financial-management/gs-chargeback-shared-services-an-aws-transit-gateway-example/) 
+  [Understand AWS data transfer details in depth from cost and usage report using Athena query and QuickSight](https://aws.amazon.com/blogs/networking-and-content-delivery/understand-aws-data-transfer-details-in-depth-from-cost-and-usage-report-using-athena-query-and-quicksight/) 
+  [Overview of Data Transfer Costs for Common Architectures (Visão geral dos custos de transferência de dados para arquiteturas comuns)](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/) 
+  [Using AWS Cost Explorer to analyze data transfer costs](https://aws.amazon.com/blogs/mt/using-aws-cost-explorer-to-analyze-data-transfer-costs/) 
+  [Cost-Optimizing your AWS architectures by utilizing Amazon CloudFront features](https://aws.amazon.com/blogs/networking-and-content-delivery/cost-optimizing-your-aws-architectures-by-utilizing-amazon-cloudfront-features/) 
+  [Como posso reduzir as taxas de transferência de dados do meu gateway NAT?](https://aws.amazon.com/premiumsupport/knowledge-center/vpc-reduce-nat-gateway-transfer-costs/) 

# Gerenciar recursos de demanda e fornecimento
<a name="a-manage-demand-and-supply-resources"></a>

**Topics**
+ [CUSTOS 9. Como gerenciar a demanda e fornecer recursos?](cost-09.md)

# CUSTOS 9. Como gerenciar a demanda e fornecer recursos?
<a name="cost-09"></a>

Para uma workload que tenha gasto e performance equilibrados, verifique se tudo o que você paga é usado e evite instâncias significativamente subutilizadas. Uma métrica de utilização distorcida em ambas as direções tem um impacto adverso sobre a organização, tanto nos custos operacionais (redução na performance em decorrência de utilização excessiva) quanto em despesas desnecessárias na AWS (devido ao excesso de provisionamento).

**Topics**
+ [COST09-BP01 Realizar uma análise sobre a demanda da workload](cost_manage_demand_resources_cost_analysis.md)
+ [COST09-BP02 Implementar um buffer ou controle de utilização para gerenciar a demanda](cost_manage_demand_resources_buffer_throttle.md)
+ [COST09-BP03 Fornecer recursos dinamicamente](cost_manage_demand_resources_dynamic.md)

# COST09-BP01 Realizar uma análise sobre a demanda da workload
<a name="cost_manage_demand_resources_cost_analysis"></a>

 Analise a demanda da workload ao longo do tempo. Garanta que a análise cubra tendências sazonais e represente com precisão as condições operacionais durante toda a vida útil da workload. O trabalho de análise deve refletir o benefício potencial (por exemplo, se o tempo gasto é proporcional ao custo da workload). 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Analisar a demanda de workload para computação em nuvem envolve entender os padrões e as características das tarefas de computação que são iniciadas no ambiente de nuvem. Essa análise ajuda os usuários a otimizar a alocação de recursos, gerenciar custos e verificar se a performance atende aos níveis exigidos. 

 Conhecer os requisitos da workload. Os requisitos da organização devem indicar os tempos de resposta da workload para solicitações. O tempo de resposta pode ser usado para determinar se a demanda é gerenciada ou se a oferta de recursos deve ser alterada para atender à demanda. 

 A análise deve incluir a previsibilidade e a repetibilidade da demanda, a taxa de alteração na demanda e a quantidade de alteração na demanda. Realize a análise durante um período longo o suficiente para incorporar qualquer variação sazonal, como processamento de fim de mês ou picos de fim de ano. 

 O trabalho de análise deve refletir os possíveis benefícios da implementação do ajuste de escala. Observe o custo total esperado do componente e os aumentos ou diminuições no uso e no custo durante a vida útil da workload. 

 Veja abaixo alguns aspectos importantes a serem considerados ao realizar a análise da demanda de workload para computação em nuvem: 

1.  **Métricas de utilização e performance de recursos**: analise como os recursos da AWS estão sendo usados ao longo do tempo. Determine padrões de uso de pico e fora do pico para otimizar as estratégias de alocação e ajuste de escala de recursos. Monitore métricas de performance, como tempos de resposta, latência, throughput e taxas de erro. Essas métricas ajudam a avaliar a integridade geral e a eficiência da infraestrutura de nuvem. 

1.  **Comportamento de escalabilidade de usuários e aplicações**: entenda o comportamento do usuário e como ele afeta a demanda da workload. Examinar os padrões de tráfego de usuários ajuda a aprimorar a entrega de conteúdo e a capacidade de resposta das aplicações. Analise como as workloads escalam com o aumento da demanda. Determine se os parâmetros de ajuste de escala automático estão configurados de forma correta e eficaz para lidar com flutuações de carga. 

1.  **Tipos de workload**: identifique os diferentes tipos de workload em execução na nuvem, como processamento em lote, processamento de dados em tempo real, aplicação web, bancos de dados ou machine learning. Cada tipo de workload pode ter requisitos de recursos e perfis de performance diferentes. 

1.  **Acordos de serviço (SLAs)**: compare a performance real com os SLAs para garantir a conformidade e identificar áreas que precisam ser aprimoradas. 

 Você pode usar o [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) para coletar e monitorar métricas, monitorar arquivos de log, definir alarmes e reagir automaticamente a mudanças nos recursos da AWS. Você também pode usar o Amazon CloudWatch para obter visibilidade sobre a utilização de recursos, a performance das aplicações e a integridade operacional em todo o sistema. 

 Com o [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/), é possível provisionar os recursos seguindo as práticas recomendadas para melhorar a performance e a confiabilidade do sistema, aumentar a segurança e procurar oportunidades de economia. Também é possível desativar o uso e as instâncias de não produção e usar o Amazon CloudWatch e o Auto Scaling para equiparar aumentos ou reduções na demanda. 

 Finalmente, você pode usar o [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) ou [Quick](https://aws.amazon.com/quicksight/) com o arquivo do AWS Cost and Usage Report (CUR) ou os logs da aplicação para realizar análises avançadas da demanda de workload. 

 No geral, uma análise abrangente da demanda da workload permite que as organizações tomem decisões embasadas sobre provisionamento, ajuste de escala e otimização de recursos, o que melhora a performance, o custo-benefício e a satisfação do usuário. 

### Etapas para a implementação
<a name="implementation-steps"></a>
+  **Analisar dados de workload existentes:** Analise dados da carga de trabalho existentes, das versões anteriores da carga de trabalho ou dos padrões de uso previstos. Use oAmazon CloudWatch, os arquivos de log e os dados de monitoramento para obter informações sobre como a workload foi usada. Analise um ciclo completo da workload e colete dados para alterações sazonais, como eventos de fim de mês ou de ano. O esforço refletido na análise deve refletir as características da workload. Deve-se concentrar o maior esforço em workloads de alto valor com as maiores alterações na demanda. Por outro lado, deve-se concentrar o menor esforço em workloads de baixo valor que tenham alterações mínimas na demanda. 
+  **Prever a influência externa:** Encontre membros da equipe de toda a organização que possam influenciar ou alterar a demanda na carga de trabalho. Equipes comuns são vendas, marketing ou desenvolvimento de negócios. Trabalhe com elas para saber os ciclos com os quais operam e se há eventos que possam alterar a demanda da workload. Preveja a demanda da workload com esses dados. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 
+  [AWS X-Ray](https://aws.amazon.com/xray/) 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [O AWS Programador de Instâncias](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) 
+  [Conceitos básicos do Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) 
+  [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 
+  [Quick](https://aws.amazon.com/quicksight/) 

 **Vídeos relacionados:** 

 **Exemplos relacionados:** 
+  [Monitorar, acompanhar e analisar em prol da otimização de custos](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/monitor-track-and-analyze/) 
+  [Searching and analyzing logs in CloudWatch](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-search-analysis.html) 

# COST09-BP02 Implementar um buffer ou controle de utilização para gerenciar a demanda
<a name="cost_manage_demand_resources_buffer_throttle"></a>

 O armazenamento em buffer e o controle de utilização modificam a demanda na carga de trabalho, suavizando todos os picos. Implemente o controle de utilização quando seus clientes realizarem novas tentativas. Implemente o armazenamento em buffer para armazenar a solicitação e adiar o processamento até um momento posterior. Verifique se os controles de utilização e buffers estão projetados para que os clientes recebam uma resposta no tempo necessário. 

 **Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 A implementação de um buffer ou controle de utilização é crucial na computação em nuvem para gerenciar a demanda e reduzir a capacidade provisionada necessária para a workload. Para um desempenho ideal, é essencial avaliar a demanda total, incluindo os picos, o ritmo das mudanças nas solicitações e o tempo de resposta necessário. Quando os clientes têm a capacidade de reenviar solicitações, é prático aplicar o controle de utilização. Entretanto, para clientes que não têm funcionalidades de repetição, a abordagem ideal é implementar uma solução de buffer. Esses buffers agilizam o influxo de solicitações e otimizam a interação de aplicações com velocidades operacionais variadas. 

![\[Demand curve with two distinct peaks that require high provisioned capacity\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/provisioned-capacity-1.png)


 Considere uma workload com a curva de demanda mostrada na figura anterior. Essa workload tem dois picos e, para lidar com eles, é provisionada a capacidade de recurso mostrada pela linha laranja. Os recursos e a energia usados para essa workload não são indicados pela área abaixo da curva da demanda, mas pela área abaixo da linha da capacidade provisionada, visto que é preciso ter capacidade provisionada para lidar com esses dois picos. Nivelar a curva da demanda pode ajudar você a reduzir a capacidade provisionada para uma workload e a diminuir o respectivo impacto ambiental. Para suavizar o pico, considere implementar uma solução de controle de utilização ou de buffer. 

 Para entendê-los melhor, vamos examinar o controle de utilização e o buffer. 

 **Controle de utilização:** se a origem da demanda tiver capacidade de repetição, você poderá implementar o controle de utilização. O controle de utilização informa à origem que, se não for possível atender à solicitação no momento, ela deverá tentar novamente mais tarde. A origem espera por um período e repete a solicitação. A implementação do controle de utilização tem a vantagem de limitar a quantidade máxima de recursos e custos da carga de trabalho. Na AWS, é possível usar o [Amazon API Gateway](https://aws.amazon.com/api-gateway/) para implementar o controle de utilização. 

 **Baseado em buffer:** uma abordagem baseada em buffer usa * produtores* (componentes que enviam mensagens para a fila), *consumidores* (componentes que recebem mensagens da fila) e uma *fila* (que contém mensagens) para armazenar as mensagens. As mensagens são lidas pelos consumidores e processadas, permitindo que as mensagens sejam executadas na taxa que atenda aos requisitos de negócios dos consumidores. Usando uma metodologia centrada em buffer, as mensagens dos produtores são armazenadas em filas ou fluxos, prontas para serem acessadas pelos consumidores em um ritmo alinhado às demandas operacionais. 

Na AWS, é possível escolher entre vários serviços para implementar uma abordagem de buffer. O [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) é um serviço gerenciado que fornece filas que permitem que um único consumidor leia mensagens individuais. O [Amazon Kinesis](https://aws.amazon.com/kinesis/) fornece um fluxo que permite que muitos consumidores leiam as mesmas mensagens.

 O buffer e o controle de utilização podem suavizar qualquer pico modificando a demanda da workload. Use o controle de utilização quando os clientes repetirem ações e use o buffer para reter a solicitação e processá-la posteriormente. Ao trabalhar com uma arquitetura com uma abordagem baseada em buffer, arquitete a workload para atender à solicitação no tempo necessário e verifique se é possível lidar com solicitações duplicadas de trabalho. Analise a demanda geral, a taxa de alteração e o tempo de resposta necessário para dimensionar adequadamente o controle ou buffer necessário. 

### Etapas da implementação
<a name="implementation-steps"></a>
+ **Analisar os requisitos do cliente:** analise as solicitações de cliente para determinar se eles podem realizar novas tentativas. Para clientes que não podem realizar novas tentativas, será necessário implementar buffers. Analise a demanda geral, a taxa de alteração e o tempo de resposta necessário para determinar o tamanho do controle de utilização ou do buffer necessário.
+ **Implementar um buffer ou um controle de utilização:** implemente um buffer ou um controle de utilização na workload. Uma fila, como o Amazon Simple Queue Service (Amazon SQS), pode fornecer um buffer para os componentes da workload. O Amazon API Gateway pode fornecer o controle de utilização para os componentes da workload. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [SUS02-BP06 Implementar armazenamento em buffer ou controle de utilização para nivelar a curva da demanda](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a7.html)
+ [REL05-BP02 Controlar a utilização de solicitações](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)

 **Documentos relacionados:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) 
+  [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 
+  [Amazon Simple Queue Service](https://aws.amazon.com/sqs/) 
+  [Conceitos básicos do Amazon SQS](https://aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) 
+  [Amazon Kinesis](https://aws.amazon.com/kinesis/) 

 **Vídeos relacionados:** 
+ [ Escolha do serviço de mensagem correto para sua aplicação distribuída ](https://www.youtube.com/watch?v=4-JmX6MIDDI)

 **Exemplos relacionados:** 
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/) (Gerenciar e monitorar o controle de utilização de API em workloads)
+ [ Throttling a tiered, multi-tenant REST API at scale using API Gateway ](https://aws.amazon.com/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-scale-using-api-gateway-part-1/)
+ [ Enabling Tiering and Throttling in a Multi-Tenant Amazon EKS SaaS Solution Using Amazon API Gateway ](https://aws.amazon.com/blogs/apn/enabling-tiering-and-throttling-in-a-multi-tenant-amazon-eks-saas-solution-using-amazon-api-gateway/)
+ [ Integração de aplicações usando filas e mensagens ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)

# COST09-BP03 Fornecer recursos dinamicamente
<a name="cost_manage_demand_resources_dynamic"></a>

Os recursos são provisionados de maneira planejada. Isso pode ser baseado na demanda, como por meio da escalabilidade automática, ou no tempo, em que a demanda é previsível e os recursos são fornecidos com base no tempo. Esses métodos ocasionam a menor quantidade de superprovisionamento ou subprovisionamento.

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Há várias maneiras de os clientes da AWS aumentarem os recursos disponíveis para suas aplicações e fornecerem recursos para atender à demanda. Uma dessas opções é usar o AWS Programador de Instâncias, que automatiza a inicialização e a interrupção das instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e do Amazon Relational Database Service (Amazon RDS). A outra opção é usar o AWS Auto Scaling, que possibilita escalar automaticamente seus recursos de computação com base na demanda de sua aplicação ou serviço. O fornecimento de recursos com base na demanda permitirá que você pague somente pelos recursos utilizados, reduza os custos lançando recursos quando eles forem necessários e os encerre quando não forem. 

 [O AWS Programador de Instâncias](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/) possibilita configurar a interrupção e o início de suas instâncias do Amazon EC2 e do Amazon RDS em horários definidos para que você possa atender à demanda pelos mesmos recursos em um padrão de tempo consistente, por exemplo, acesso diário dos usuários às instâncias do Amazon EC2 às 8h, que não são necessárias após as 18h. Essa solução ajuda a reduzir o custo operacional interrompendo recursos que não estão sendo usados e iniciá-los quando eles são necessários. 

![\[Diagrama mostrando a otimização de custos com o uso do AWS Programador de Instâncias.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/instance-scheduler-diagram.png)


 

Você também pode configurar facilmente programações para suas instâncias do Amazon EC2 em suas contas e regiões com uma interface de usuário (IU) simples usando a Configuração rápida do AWS Systems Manager. É possível programar instâncias do Amazon EC2 e do Amazon RDS com o AWS Programador de Instâncias e interromper e iniciar instâncias existentes. No entanto, você não pode interromper e iniciar instâncias que façam parte de seu grupo do Auto Scaling (ASG) nem que gerenciem serviços, como o Amazon Redshift ou o Amazon OpenSearch Service. Os grupos do Auto Scaling têm seu próprio agendamento para as instâncias no grupo e essas instâncias são criadas. 

[O AWS Auto Scaling](https://aws.amazon.com/autoscaling/) ajuda você a ajustar sua capacidade para manter uma performance estável e previsível pelo menor custo possível para atender às variações de demanda. Trata-se de um serviço totalmente gerenciado e gratuito para escalar a capacidade de sua aplicação que se integra a instâncias do Amazon EC2 e frotas spot, Amazon ECS, Amazon DynamoDB e Amazon Aurora. O Auto Scaling oferece descoberta automática de recursos para ajudar a encontrar recursos na sua workload que possam ser configurados, tem estratégias de ajuste de escala incorporadas para otimizar a performance, os custos ou um equilíbrio entre os dois, além de oferecer escalabilidade preditiva para ajudar com picos que ocorrem regularmente. 

 Há várias opções de ajuste de escala disponíveis para escalar seu grupo do Auto Scaling: 
+  Manter os níveis de instância atuais em todos os momentos 
+  Escalar manualmente 
+  Escalar com base em um cronograma 
+  Escalar com base na demanda 
+  Usar o ajuste de escala preditivo 

 As políticas do Auto Scaling diferem e podem ser categorizadas como políticas de ajuste de escala dinâmico e programado. As políticas dinâmicas são ajuste de escala manual ou dinâmico, ajuste de escala programado ou preditivo. Você pode usar políticas para ajuste de escala dinâmico, programado e preditivo. Também é possível usar métricas e alarmes do [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) para acionar eventos de escalabilidade para sua workload. Recomendamos que você use [modelos de lançamento](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html), que permitem acessar os recursos e melhorias mais recentes. Nem todos os recursos do Auto Scaling estão disponíveis quando você usa as configurações de inicialização. Por exemplo, você não pode criar um grupo do Auto Scaling que inicie instâncias spot e sob demanda nem que especifique vários tipos de instância. Você deve usar um modelo de inicialização para configurar esses recursos. Ao usar modelos de inicialização, recomendamos que você crie a versão de cada um. Com o versionamento dos modelos de inicialização, você pode criar um subconjunto do conjunto completo de parâmetros. Depois, é possível reutilizá-lo para criar outras versões do mesmo modelo de inicialização. 

 É possível usar o AWS Auto Scaling ou incorporar ajuste de escala em seu código com as [APIs da AWS ou SDKs](https://aws.amazon.com/developer/tools/). Isso reduz os custos gerais da workload removendo o custo operacional de fazer alterações manualmente em seu ambiente, e alterações podem ser realizadas muito mais rapidamente. Isso também atende à mobilização de recursos da workload de acordo com sua demanda a qualquer momento. Para seguir essa prática recomendada e fornecer recursos de forma dinâmica para sua organização, você precisa entender a escalabilidade horizontal e vertical na Nuvem AWS, bem como a natureza das aplicações executadas em instâncias do Amazon EC2. É melhor para sua equipe de gerenciamento financeiro na nuvem trabalhar com equipes técnicas a fim de seguir essa prática recomendada. 

 [O Elastic Load Balancing (Elastic Load Balancing)](https://aws.amazon.com/elasticloadbalancing/) ajuda a escalar distribuindo a demanda entre vários recursos. Com o uso do ASG e do Elastic Load Balancing, você pode gerenciar as solicitações recebidas roteando o tráfego de forma ideal para que nenhuma instância fique sobrecarregada em um grupo do Auto Scaling. As solicitações seriam distribuídas entre todos os destinos de um grupo-alvo de forma contínua, sem considerar a capacidade nem a utilização. 

 As métricas típicas podem ser métricas padrão do Amazon EC2, como utilização de CPU, throughput de rede e latência de solicitação/resposta observada pelo Elastic Load Balancing. Quando possível, você deve usar uma métrica que seja indicativa da experiência do cliente. Normalmente é uma métrica personalizada que pode se originar do código da aplicação em sua workload. Para elaborar como atender à demanda dinamicamente neste documento, vamos agrupar o Auto Scaling em duas categorias, como modelos de fornecimento baseados na demanda e baseados no tempo, e nos aprofundarmos em cada uma delas. 

**Fornecimento baseado em demanda:** Utilize a elasticidade da nuvem para fornecer recursos para atender às mudanças na demanda, confiando no estado de demanda quase em tempo real. Para fornecimento baseado em demanda, use as APIs ou os recursos de serviço para variar programaticamente a quantidade de recursos de nuvem em sua arquitetura. Isso permite que você ajuste a escala de componentes em sua arquitetura e aumente o número de recursos durante picos de demanda a fim de manter a performance e reduzir a capacidade quando a demanda diminui para reduzir os custos. 

![\[Diagrama descrevendo as políticas de ajuste de escala com base na demanda, como ajuste de escala simples/em etapas e rastreamento de metas.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/demand-based-supply.png)


 
+  **Ajuste de escala simples/em etapas:** Monitora métricas e adiciona/remove instâncias de acordo com as etapas definidas manualmente pelos clientes. 
+  **Monitoramento de objetivo:** Mecanismo de controle semelhante a um termostato que adiciona ou remove instâncias automaticamente para manter as métricas em uma meta definida pelo cliente. 

Ao arquitetar com uma abordagem baseada em demanda, tenha em mente dois pontos essenciais. Primeiro, entenda a rapidez com que você deve provisionar novos recursos. Segundo, entenda que o tamanho da margem entre oferta e demanda mudará. Você deve estar pronto para lidar com a taxa de alteração na demanda e também estar pronto para falhas de recursos.

**Oferta baseada em tempo:** Uma abordagem baseada em tempo alinha a capacidade de recurso a uma demanda que é previsível ou bem definida no tempo. Essa abordagem costuma não depender dos níveis de utilização dos recursos. Uma abordagem baseada em tempo garante que os recursos estejam disponíveis no momento específico em que são necessários e podem ser fornecidos sem nenhum atraso devido a procedimentos de inicialização e verificações do sistema ou de consistência. Usando uma abordagem baseada em tempo, você pode fornecer recursos adicionais ou aumentar a capacidade durante períodos ocupados.

![\[Diagrama descrevendo as políticas de ajuste de escala baseado em tempo, como ajuste de escala programado e preditivo.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/time-based-supply.png)


 

Você pode usar o ajuste de escala automático programado ou preditivo para implementar uma abordagem baseada em tempo. As workloads podem ser programadas para aumentar ou reduzir a escala horizontalmente em horários definidos (por exemplo, o início do horário comercial), tornando os recursos disponíveis quando os usuários chegarem ou a demanda aumentar. A escalabilidade preditiva usa padrões para aumentar a escala horizontalmente enquanto a escalabilidade programada usa horários predefinidos para isso. Você também pode usar [a estratégia de seleção de tipo de instância baseada em atributos (ABS)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) em grupos do Auto Scaling, o que permite que você expresse seus requisitos de instância como um conjunto de atributos, como vCPU, memória e armazenamento. Isso permite usar automaticamente os tipos de instância de geração mais recente quando eles são lançados e acessar uma variedade mais ampla de capacidade com instâncias spot do Amazon EC2. A frota do Amazon EC2 e o Amazon EC2 Auto Scaling selecionam e executam instâncias que se ajustam aos atributos especificados, eliminando a necessidade de escolher manualmente os tipos de instância. 

Você também pode aproveitar as [APIs da AWS e os SDKs](https://aws.amazon.com/developer/tools/) e o [AWS CloudFormation](https://aws.amazon.com/cloudformation/) para provisionar e desativar automaticamente ambientes inteiros conforme necessário. Essa abordagem é adequada para ambientes de desenvolvimento ou teste que são executados apenas nos períodos ou horários comerciais definidos. Você pode usar APIs para ajustar a escala dos recursos dentro de um ambiente (ajuste de escala vertical). Por exemplo, você pode escalar uma workload de produção alterando o tamanho ou a classe da instância. Isso pode ser feito interrompendo e iniciando a instância e selecionando a classe ou o tamanho da instância diferente. Essa técnica também pode ser aplicada a outros recursos, como Volumes Elásticos do Amazon EBS, que podem ser modificados para aumentar o tamanho, ajustar a performance (IOPS) ou alterar o tipo de volume durante o uso.

Ao arquitetar com uma abordagem baseada em tempo, tenha em mente dois pontos essenciais. Primeiro, qual é a consistência do padrão de uso? Segundo, qual será o impacto se o padrão mudar? Você pode aumentar a precisão das previsões monitorando suas workloads e usando inteligência de negócios. Se você vir alterações significativas no padrão de uso, poderá ajustar os tempos para garantir que a cobertura seja fornecida.

## Etapas da implementação
<a name="implementation-steps"></a>
+ ** Configure o ajuste de escala programado: **Para alterações previsíveis na demanda, o ajuste de escala baseado em tempo pode fornecer a quantidade correta de recursos em tempo hábil. Também será útil se a criação e a configuração de recursos não forem rápidas o suficiente para responder a alterações na demanda. Usando a análise de workload, configure a escalabilidade programada usando o AWS Auto Scaling. Para configurar a programação baseada em tempo, você pode usar o ajuste de escala preditivo do ajuste de escala programado para aumentar o número de instâncias do Amazon EC2 em seus grupos do Auto Scaling com antecedência de acordo com as alterações de carga esperadas ou previsíveis.
+  **Configure o ajuste de escala preditivo:** O ajuste de escala preditivo permite aumentar com antecedência o número de instâncias do Amazon EC2 em seu grupo do Auto Scaling de padrões diários e semanais nos fluxos de tráfego. Se você tiver picos de tráfego regulares e aplicações que levem muito tempo para serem iniciadas, considere usar a escalabilidade preditiva. A escalabilidade preditiva pode ajudar você a escalar com maior rapidez inicializando a capacidade antes da carga projetada em comparação com a escalabilidade dinâmica isolada, que é reativa por natureza. Por exemplo, se os usuários começarem a usar sua workload no início do horário comercial e não usá-la após o expediente, a escalabilidade preditiva poderá adicionar capacidade antes do horário comercial, o que elimina o atraso da escalabilidade dinâmica para reagir à mudança no tráfego. 
+ ** Configure o ajuste de escala automático dinâmico: **Para configurar o ajuste de escala com base nas métricas ativas da workload, use o Auto Scaling. Use a análise e configure o Auto Scaling para iniciar nos níveis de recursos corretos e garanta que a workload escale no tempo necessário. Você pode iniciar e dimensionar automaticamente uma frota de instâncias sob demanda e instâncias spot em um único grupo do Auto Scaling. Além de receber descontos pelo uso de instâncias spot, você pode usar instâncias reservadas ou um Savings Plan para receber taxas com desconto do preço regular da instância sob demanda. Todos esses fatores combinados ajudam você a otimizar sua economia de custos para instâncias do Amazon EC2 e determinar a escala e a performance desejadas para sua aplicação.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [O AWS Programador de Instâncias](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) 
+  Escalar o tamanho de seu grupo do Auto Scaling 
+  [Conceitos básicos do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Conceitos básicos do Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) 
+  [Ajuste de escala programado para Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
+ [ Ajuste de escala preditivo para Amazon EC2 Auto Scaling ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html)

 **Vídeos relacionados:** 
+ [ Políticas de ajuste de escala com monitoramento de objetivo para o Auto Scaling ](https://www.youtube.com/watch?v=-RumeaoPB2M)
+ [ O AWS Programador de Instâncias ](https://www.youtube.com/watch?v=nTLEyo2NzUs)

 **Exemplos relacionados:** 
+ [ Attribute based Instance Type Selection for Auto Scaling for Amazon EC2 Fleet (Seleção de tipo de instância baseada em atributo do Auto Scaling para a frota do Amazon EC2) ](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [ Optimizing Amazon Elastic Container Service for cost using scheduled scaling (Otimização do Amazon Elastic Container Service para o custo usando ajuste de escala programado) ](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [ Ajuste de escala com o Amazon EC2 Auto Scaling ](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [ How do I use Instance Scheduler with CloudFormation to schedule Amazon EC2 instances? (Como usar o Programador de Instâncias com o CloudFormation para programar as instâncias do Amazon EC2?) ](https://aws.amazon.com/premiumsupport/knowledge-center/stop-start-instance-scheduler/)

# Otimizar ao longo do tempo
<a name="a-optimize-over-time"></a>

**Topics**
+ [CUSTOS 10. Como avaliar os novos serviços?](cost-10.md)
+ [CUSTOS 11. Como avaliar o custo do esforço?](cost-11.md)

# CUSTOS 10. Como avaliar os novos serviços?
<a name="cost-10"></a>

À medida que a AWS lança novos serviços e recursos, uma das práticas recomendadas é avaliar suas decisões sobre a arquitetura existente, a fim de garantir que elas ofereçam o melhor custo-benefício.

**Topics**
+ [COST10-BP01 Desenvolver um processo de análise da workload](cost_evaluate_new_services_review_process.md)
+ [COST10-BP02 Revisar e analisar a workload regularmente](cost_evaluate_new_services_review_workload.md)

# COST10-BP01 Desenvolver um processo de análise da workload
<a name="cost_evaluate_new_services_review_process"></a>

 Desenvolva um processo que defina os critérios e o processo para análise da workload. O esforço de análise deve refletir o benefício potencial. Por exemplo, workloads principais ou workloads com valor superior a 10% da fatura são analisadas trimestralmente ou a cada seis meses, enquanto workloads abaixo de 10% são analisadas anualmente. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>

Para ter a workload mais econômica, você deve revisar regularmente a workload para saber se há oportunidades de implementar novos serviços, recursos e componentes. Para obter custos gerais mais baixos, o processo deve ser proporcional à quantidade potencial de economia. Por exemplo, as workloads que representam 50% do seu gasto geral devem ser analisadas com mais frequência e mais precisão do que as workloads que representam 5% do seu gasto geral. Leve em consideração quaisquer fatores externos ou volatilidade. Se a workload atender a uma área geográfica ou segmento de mercado específico e houver previsão de mudanças nessa área, revisões mais frequentes poderão resultar em economias de custos. Outro fator em análise é o esforço para implementar alterações. Se houver custos significativos em testes e validação de alterações, as revisões devem ser menos frequentes. 

Leve em consideração o custo de longo prazo de manutenção de componentes e recursos obsoletos e na incapacidade de implementar novos recursos neles. O custo atual de testes e validação pode exceder o benefício proposto. No entanto, ao longo do tempo, o custo de fazer a mudança pode aumentar significativamente à medida que a lacuna entre a workload e as tecnologias atuais aumenta, resultando em custos ainda maiores. Por exemplo, o custo da migração para uma nova linguagem de programação pode não ser econômico no momento. No entanto, em cinco anos, o custo de pessoas com qualificações nessa linguagem pode aumentar e, devido ao crescimento da workload, você estaria movendo um sistema ainda maior para a nova linguagem, exigindo ainda mais esforço do que anteriormente. 

Divida sua workload em componentes, atribua o custo do componente (uma estimativa é suficiente) e liste os fatores (por exemplo, esforço e mercados externos) ao lado de cada componente. Use esses indicadores para determinar uma frequência de revisão para cada workload. Por exemplo, você pode ter servidores web como um alto custo, baixo esforço de alteração e altos fatores externos, resultando em alta frequência de revisão. Um banco de dados central pode ser de custo médio, alto esforço de alteração e baixos fatores externos, resultando em uma média frequência de análise. 

 Defina um processo para avaliar novos serviços, padrões de design, tipos de recursos e configurações para otimizar o custo de sua workload conforme ficarem disponíveis. Semelhante aos processos de [análise de pilar de performance](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf-06.html) e [análise de pilar de confiabilidade](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_monitor_aws_resources_review_monitoring.html), identifique, valide e priorize as atividades de otimização e aprimoramento e correção de problemas e incorpore isso ao seu backlog. 

**Etapas da implementação**
+  **Definição da frequência de análise: **defina a frequência com que a workload e os componentes dela devem ser analisados. Aloque tempo e recursos para o aprimoramento contínuo e analise a frequência para melhorar a eficiência e a otimização de sua workload. Essa é uma combinação de fatores e pode diferir de workload para workload em sua organização e entre componentes na workload. Os fatores comuns incluem: a importância para a organização medida em termos de receita ou marca, o custo total da execução da workload (incluindo custos operacionais e de recursos), a complexidade da workload, a facilidade da implementação de uma alteração, qualquer contrato de licenciamento de software e se uma alteração geraria aumentos significativos nos custos de licenciamento devido a licenciamento punitivo. Os componentes podem ser definidos de maneira funcional ou técnica, como bancos de dados e servidores web ou recursos de computação e armazenamento. Equilibre os fatores de acordo e desenvolva um período para a workload e os componentes dela. Você pode decidir analisar a workload completa a cada 18 meses, analisar os servidores web a cada seis meses, o banco de dados a cada doze meses, a computação e o armazenamento de curto prazo a cada seis meses e o armazenamento de longo prazo a cada doze meses.
+ ** Definição da minuciosidade da análise: **defina quanto esforço é gasto na análise da workload ou dos componentes dela. Semelhante à frequência da análise, esse é um equilíbrio de vários fatores. Avalie e priorize oportunidades de melhorias para concentrar os esforços nos locais onde eles oferecem os maiores benefícios enquanto calcula quanto esforço é necessário para essas atividades. Se os resultados esperados não satisfizerem às metas e o esforço necessário custar mais, itere usando cursos de ação alternativos. Seus processos de análise devem incluir tempo e recursos dedicados para possibilitar melhorias incrementais contínuas. Por exemplo, você pode decidir gastar uma semana de análise no componente do banco de dados, uma semana de análise para recursos computacionais e quatro horas para análises de armazenamento.

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [ Blog de novidades da AWS](https://aws.amazon.com/blogs/aws/) 
+  [Tipos de computação em nuvem](https://aws.amazon.com/types-of-cloud-computing/) 
+  [Quais as novidades da AWS](https://aws.amazon.com/new/) 

 **Exemplos relacionados:** 
+ [AWS Support Proactive Services ](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) (Serviços proativos do AWS Support)
+ [ Regular workload reviews for SAP workloads ](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/best-practice-4-4.html) (Análises regulares de workloads SAP)

# COST10-BP02 Revisar e analisar a workload regularmente
<a name="cost_evaluate_new_services_review_workload"></a>

As workloads existentes são revisadas regularmente com base em cada processo definido para descobrir se é possível adotar novos serviços, substituir serviços já em vigor ou reprojetar workloads.

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

A AWS sempre adiciona novos recursos para que você possa experimentar e novar mais rápido com a tecnologia mais recente. [Novidades da AWS](https://aws.amazon.com/new/) detalha como a AWS está fazendo isso e oferece uma breve visão geral dos anúncios de expansão regional, dos recursos e dos serviços da AWS assim que eles são lançados. Você pode examinar detalhadamente os lançamentos que foram anunciados e usá-los para revisar e analisar suas workloads existentes. Para obter os benefícios de novos serviços e recursos da AWS, analise suas workloads e implemente novos serviços e recursos conforme necessário. Isso significa que você pode precisar substituir os serviços que você usa para a workload ou modernizar a workload para adotar novos serviços da AWS. Por exemplo, você pode analisar suas workloads e substituir o componente de mensagens pelo Amazon Simple Email Service. Isso remove o custo de operação e manutenção de uma frota de instâncias e, ao mesmo tempo, fornece toda a funcionalidade a um custo reduzido. 

 Para analisar sua workload e destacar possíveis oportunidades, você deve considerar não apenas novos serviços, mas também novas formas de criar soluções. Examine os vídeos [Esta é a minha arquitetura](https://aws.amazon.com/architecture/this-is-my-architecture) na AWS para conhecer designs de arquitetura de outros clientes, seus desafios e suas soluções. Confira a série [Tudo incluído](https://aws.amazon.com/architecture/all-in-series/) para descobrir aplicações reais dos serviços da AWS e conhecer histórias de clientes. Você também pode assistir à série de vídeo [De volta ao básico](https://aws.amazon.com/architecture/back-to-basics/), que explica, examina e detalha práticas recomendadas do padrão de arquitetura de nuvem básica. Outra fonte são os vídeos [Como construir isso](https://aws.amazon.com/architecture/how-to-build-this/), que são projetados para ajudar as pessoas em grandes ideias sobre como viabilizar seu produto mínimo viável (MVP) usando serviços da AWS. Desse modo, criadores do mundo inteiro que tiverem uma grande ideia poderão obter orientações arquiteturais de arquitetos de soluções experientes da AWS. Por fim, você pode examinar os materiais do recurso [Conceitos básicos](https://aws.amazon.com/getting-started/), que tem tutoriais detalhados. 

 Antes de executar seu processo de avaliação, siga os requisitos de sua empresa com relação a workload, segurança e privacidade dos dados para usar requisitos específicos de serviço ou de região e performance e, ao mesmo tempo, siga o processo de avaliação que foi acordado. 

**Etapas da implementação**
+ ** Avaliação regular da workload: **usando o processo definido, realize avaliações na frequência especificada. Verifique se você despendeu a quantidade correta de esforço em cada componente. Esse processo seria semelhante ao processo de design inicial em que você selecionou serviços para otimização de custos. Analise os serviços e os benefícios que eles trariam, esse fator de tempo no custo de fazer a mudança, e não apenas os benefícios de longo prazo. 
+ ** Implementação de novos serviços:** se o resultado da análise for implementar alterações, primeiro execute uma linha de base da workload para saber o custo atual por saída. Implemente as alterações e, em seguida, execute uma análise para confirmar o novo custo por saída. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [ Blog de novidades da AWS](https://aws.amazon.com/blogs/aws/) 
+  [Quais as novidades da AWS](https://aws.amazon.com/new/) 
+ [ Documentação da AWS](https://docs.aws.amazon.com/)
+ [ Conceitos básicos da AWS](https://aws.amazon.com/getting-started/)
+ [ Recursos gerais da AWS](https://docs.aws.amazon.com/#general_resources)

 **Vídeos relacionados:** 
+  [AWS: Esta é a minha arquitetura](https://aws.amazon.com/architecture/this-is-my-architecture) 
+  [AWS: De volta ao básico](https://aws.amazon.com/architecture/back-to-basics/) 
+  [AWS: Série Tudo Incluído](https://aws.amazon.com/architecture/all-in-series/) 
+  [Como construir isso](https://aws.amazon.com/architecture/how-to-build-this/) 

# CUSTOS 11. Como avaliar o custo do esforço?
<a name="cost-11"></a>

**Topics**
+ [COST11-BP01 Realizar automações nas operações](cost_evaluate_cost_effort_automations_operations.md)

# COST11-BP01 Realizar automações nas operações
<a name="cost_evaluate_cost_effort_automations_operations"></a>

 Avalie o custo de esforço das operações na nuvem. Redução da quantidade de tempo e esforço em tarefas administrativas, implantação e outras operações usando a automação. Avalie o tempo e custo necessários ao esforço de operações e à automatização de tarefas administrativas para reduzir o esforço humano quando possível. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

 A automatização de processos melhora a consistência e a escalabilidade, oferece maior visibilidade, confiabilidade e flexibilidade, reduz os custos e acelera a inovação ao liberar recursos humanos e aperfeiçoar as métricas. Ela reduz a frequência das tarefas manuais, melhora a eficiência e beneficia as empresas por fornecer uma experiência consistente e confiável em implantação, administração ou operação de workloads. Você pode liberar recursos de infraestrutura de tarefas operacionais manuais e usá-los para tarefas e inovações de maior valor e, consequentemente, melhorar os resultados dos negócios. As empresas necessitam de um método comprovado e testado para gerenciar suas workloads na nuvem. Essa solução precisa ser segura, rápida e econômica, e oferecer risco mínimo e confiabilidade máxima. 

 Primeiro, priorize suas operações com base no esforço necessário examinando o custo geral das operações na nuvem. Por exemplo, quanto tempo se leva para implantar novos recursos na nuvem, realizar alterações de otimização nos recursos existentes ou implementar as configurações necessárias? Examine o custo total das ações humanas incluindo o custo de operações e gerenciamento como fator. Priorize a automação das tarefas administrativas para reduzir o esforço humano. A avaliação do esforço deve refletir o provável benefício. Por exemplo, tempo gasto na execução de tarefas manuais em contraposição a tarefas automáticas. Priorize a automatização de atividades de alto valor repetitivas. As atividades que apresentam um risco maior de erro humano normalmente são o melhor lugar para começar a automatizar porque, com frequência, o risco cria um custo operacional adicional não desejado (como horas extras de trabalho da equipe de operações). 

 Usando as ferramentas e os serviços da AWS ou produtos de terceiros, você pode escolher quais automações da AWS deve implementar e personalizar para suas necessidades específicas. A tabela abaixo mostra alguns recursos e funções essenciais de operações que você pode obter com os serviços da AWS para automatizar a administração e operação: 
+  [AWS Audit Manager](https://aws.amazon.com/audit-manager/): audite continuamente seu uso da AWS para simplificar a avaliação de risco e conformidade 
+  [AWS Backup](https://aws.amazon.com/backup/): gerencie centralmente e automatize a proteção de dados. 
+  [AWS Config](https://aws.amazon.com/config/): configure recursos de computação, avalie, audite e estime o valor das configurações e do inventário de recursos. 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/): lance recursos altamente disponíveis com infraestrutura como código. 
+  [AWS CloudTrail](https://aws.amazon.com/cloudtrail/): gerenciamento de mudanças de TI, conformidade e controle. 
+  [Amazon EventBridge](https://aws.amazon.com/eventbridge/): programe eventos e acione o AWS Lambda para que ele tome medidas. 
+  [AWS Lambda](https://aws.amazon.com/lambda/): automatize processos repetitivos acionando-os com eventos ou executando-os em uma programação fixa com o Amazon EventBridge. 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/): inicie e interrompa workloads, aplique patches em sistemas operacionais e automatize a configuração e o gerenciamento contínuo. 
+  [AWS Step Functions](https://aws.amazon.com/step-functions/): programe trabalhos e automatize fluxos de trabalho. 
+  [AWS Service Catalog](https://aws.amazon.com/servicecatalog/): crie modelos de consumo e infraestrutura como código com conformidade e controle. 

 Considere a economia de tempo que permitirá que sua equipe se concentre na retirada de recursos de endividamento técnico, inovação e agregação de valor. Por exemplo, talvez você precise mover sem alterações (lift-and-shift) seu ambiente on-premises para a nuvem o mais rapidamente possível e otimizar em outro momento. Vale a pena explorar as economias que você poderia obter usando serviços totalmente gerenciados da AWS que eliminam ou reduzem custos de licença, como [Amazon Relational Database Service](https://aws.amazon.com/rds/), [Amazon EMR](https://aws.amazon.com/emr/), [Amazon WorkSpaces](https://aws.amazon.com/workspaces/) e [Amazon SageMaker AI](https://aws.amazon.com/sagemaker/). serviços gerenciados eliminam a sobrecarga operacional e administrativa da manutenção de um serviço, o que permite que você se concentre na inovação. Além disso, como serviços gerenciados operam em escala da nuvem, eles podem oferecer menor custo por transação ou serviço. 

 Se você quiser adotar automações imediatamente usando produtos e serviços da AWS e se não tiver habilidades em sua organização, entre em contato com o [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/), [AWS Professional Services](https://aws.amazon.com/professional-services/) ou com [parceiros da AWS](https://aws.amazon.com/partners/work-with-partners/) para ampliar a adoção da automação e melhorar sua excelência operacional na nuvem. 

 [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) é um serviço que opera a infraestrutura da AWS em nome de clientes e parceiros empresariais. Ele fornece um ambiente seguro e compatível no qual você pode implantar suas workloads. O AMS usa modelos operacionais de nuvem empresarial com automação para permitir que você atenda aos requisitos da sua organização, migre para a nuvem mais rapidamente e reduza seus custos de gerenciamento constantes. 

 O [AWS Professional Services](https://aws.amazon.com/professional-services/) também pode ajudar você a alcançar os resultados de negócios que deseja e a automatizar as operações com a AWS. Com o AWS Professional Services, você tem acesso a práticas de especialidade globais para apoiar suas iniciativas em áreas focalizadas de computação em nuvem empresarial. As disciplinas especializadas oferecem orientações direcionadas por meio de práticas recomendadas, frameworks, ferramentas e serviços em áreas do conhecimento industrial, de solução e de tecnologia. Elas ajudam os cliente a implantar operações de TI automatizadas, robustas e ágeis, bem como recursos de governança otimizados para o centro da nuvem. 

 **Etapas da implementação** 
+  **Construir uma vez e implantar várias:** use infraestrutura como código como o AWS CloudFormation, AWS SDKs ou a AWS Command Line Interface (AWS CLI) para implantar uma vez e usar várias vezes para o mesmo ambiente ou para cenários de recuperação de desastres. Marque e, ao mesmo tempo, monitore seu consumo tal como definido em outras práticas recomendadas. Use o [AWS Launch Wizard](https://aws.amazon.com/launchwizard/) para reduzir o tempo para implantar várias workloads empresariais conhecidas. O AWS Launch Wizard orienta você sobre tamanho, configuração e implantação de workloads empresariais seguindo práticas recomendadas da AWS. Também é possível usar o [AWS Service Catalog](https://aws.amazon.com/servicecatalog/), que ajuda você a criar e gerenciar modelos aprovados de infraestrutura como código para uso na AWS. Desse modo, qualquer pessoa pode descobrir recursos de nuvem de autoatendimento aprovados. 
+  **Automatizar operações:** execute operações de rotina automaticamente sem intervenção humana. Usando as ferramentas e os serviços da AWS, você pode escolher quais automações da AWS deve implementar e personalizar para suas necessidades específicas. Por exemplo, use [EC2 Image Builder](https://aws.amazon.com/image-builder/) para criar, testar e implantar imagens de máquina virtual e contêiner para uso na AWS ou em ambiente on-premises. Se a ação que você deseja não puder ser realizada com serviços da AWS ou você precisar de ações mais complexas com recursos de filtragem, automatize suas operações usando a [AWS CLI](https://aws.amazon.com/cli/index.html) ou ferramentas dos AWS SDKs. A AWS CLI oferece a possibilidade de automatizar o processo completo de controle e gerenciamento de serviços da AWS por meio de scripts sem usar o Console da AWS. Selecione os AWS SDKs de sua preferência para interagir com os serviços da AWS. Para outros exemplos de código, consulte [Repositório de exemplos de código de AWS SDKs](https://github.com/awsdocs/aws-doc-sdk-examples). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Modernização de operações na Nuvem AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-operations-integration/welcome.html)
+ [Serviços da AWS para automação](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-operations-integration/aws-services-for-automation.html)
+ [AWS Systems Manager Automation ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [ Automações da AWS para administração e operações SAP](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-sap-automation/automations.html)
+ [AWS Managed Services](https://aws.amazon.com/managedservices/index.html)
+ [AWS Professional Services ](https://aws.amazon.com/professional-services/)
+ [ Infraestrutura e automação ](https://aws.amazon.com/blogs/infrastructure-and-automation/)

 **Exemplos relacionados:** 
+ [ Reinvenção das operações automatizadas (Parte I) ](https://aws.amazon.com/blogs/mt/reinventing-automated-operations-part-i/)
+ [ Reinvenção das operações automatizadas (Parte II) ](https://aws.amazon.com/blogs/mt/reinventing-automated-operations-part-ii/)
+ [ Automações da AWS para administração e operações SAP](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-sap-automation/automations.html)
+ [ Automações de TI com o AWS Lambda](https://aws.amazon.com/lambda/it-automation/)
+ [ Repositório de exemplos de código da AWS](https://github.com/awsdocs/aws-doc-sdk-examples)
+ [ Amostras da AWS](https://github.com/aws-samples)

# Sustentabilidade
<a name="a-sustainability"></a>

O pilar Sustentabilidade abrange ações como compreender os impactos dos serviços usados, quantificá-los ao longo do ciclo de vida da workload e aplicar princípios e práticas recomendadas de design para reduzi-los ao criar workloads na nuvem. Você pode encontrar orientações prescritivas sobre implementação no [Whitepaper sobre o pilar Sustentabilidade](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp).

**Topics**
+ [Seleção de região](a-region-selection.md)
+ [Alinhamento com a demanda](a-alignment-to-demand.md)
+ [Software e arquitetura](a-sus-software-architecture.md)
+ [Dados](a-sus-data.md)
+ [Hardware e serviços](a-sus-hardware-and-services.md)
+ [Processo e cultura](a-sus-process-and-culture.md)

# Seleção de região
<a name="a-region-selection"></a>

**Topics**
+ [SUS 1 Como selecionar regiões para sua workload?](w2aac19c17b7b5.md)

# SUS 1 Como selecionar regiões para sua workload?
<a name="w2aac19c17b7b5"></a>

A escolha da região para sua workload afeta significativamente seus KPIs, incluindo desempenho, custo e pegada de carbono. Para melhorar efetivamente esses KPIs, você deve escolher regiões para suas workloads com base em requisitos empresariais e metas de sustentabilidade.

**Topics**
+ [SUS01-BP01 Escolher a região com base nos requisitos empresariais e nas metas de sustentabilidade](sus_sus_region_a2.md)

# SUS01-BP01 Escolher a região com base nos requisitos empresariais e nas metas de sustentabilidade
<a name="sus_sus_region_a2"></a>

Escolha uma região para sua workload com base em seus requisitos empresariais e metas de sustentabilidade para otimizar seus KPIs, incluindo desempenho, custo e pegada de carbono.

 **Antipadrões comuns:** 
+  Selecione a região da workload com base em sua localização. 
+  Você consolida todos os recursos da workload em uma única localização geográfica. 

 **Benefícios de estabelecer esta prática recomendada:** Colocar uma workload próxima a projetos de energia renovável da Amazon ou regiões com baixa intensidade de carbono publicada pode ajudar a reduzir a pegada de carbono de uma workload na nuvem. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

O Nuvem AWS é uma rede em constante expansão de regiões e pontos de presença (PoP), com uma infraestrutura de rede global que os conecta. A escolha da região para sua workload afeta significativamente seus KPIs, incluindo desempenho, custo e pegada de carbono. Para melhorar efetivamente esses KPIs, você deve escolher regiões para sua workload com base em seus requisitos empresariais e metas de sustentabilidade.

 **Etapas da implementação** 
+  Siga estas etapas para avaliar e selecionar possíveis regiões para sua workload com base em seus requisitos de negócios, incluindo conformidade, recursos disponíveis, custo e latência: 
  +  Confirme se essas regiões estão em conformidade, com base nos regulamentos locais exigidos. 
  +  Use as [Listas de serviços regionais do AWS](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) para verificar se as regiões têm os serviços e recursos necessários para executar sua workload. 
  +  Calcule o custo da workload em cada região usando o [AWS Calculadora de Preços](https://calculator.aws/). 
  +  Teste a latência de rede entre as localizações de seus usuários finais e cada Região da AWS. 
+  Escolha regiões próximas aos projetos de energia renovável da Amazon e regiões onde a grade de intensidade de carbono publicada esteja abaixo de outros locais (ou regiões). 
  +  Identifique suas diretrizes de sustentabilidade relevantes para rastrear e comparar as emissões de carbono ano a ano com base no [GHG Protocol](https://ghgprotocol.org/) (métodos baseados no mercado e baseados na localização). 
  +  Escolha a região com base no método que você usa para rastrear as emissões de carbono. Para obter mais detalhes sobre como escolher uma região com base em suas diretrizes de sustentabilidade, consulte [Como selecionar uma região para sua workload com base nas metas de sustentabilidade](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Compreensão de suas estimativas de emissão de carbono](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ccft-estimation.html) 
+  [Amazon em todo o mundo](https://sustainability.aboutamazon.com/about/around-the-globe?energyType=true) 
+  [Metodologia de energia renovável](https://sustainability.aboutamazon.com/amazon-renewable-energy-methodology) 
+  [O que considerar ao selecionar uma região para suas workloads](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/) 

 **Vídeos relacionados:** 
+  [Arquitetura sustentável e redução de sua pegada de carbono do AWS](https://www.youtube.com/watch?v=jsbamOLpCr8) 

# Alinhamento com a demanda
<a name="a-alignment-to-demand"></a>

**Topics**
+ [SUS 2 Como alinhar recursos de nuvem à sua demanda?](sus-02.md)

# SUS 2 Como alinhar recursos de nuvem à sua demanda?
<a name="sus-02"></a>

A maneira como os usuários e as aplicações consomem suas workloads e outros recursos pode ajudar você a identificar melhorias para atingir as metas de sustentabilidade. Escale a infraestrutura de forma que ela corresponda à demanda e use apenas os recursos mínimos necessários para oferecer suporte aos usuários. Alinhe os níveis de serviço às necessidades do cliente. Posicione os recursos a fim de limitar a rede necessária para que usuários e aplicações os consumam. Elimine ativos não utilizados. Forneça aos membros da sua equipe dispositivos compatíveis com suas necessidades e minimize o impacto na sustentabilidade.

**Topics**
+ [SUS02-BP01 Escalar a infraestrutura da workload dinamicamente](sus_sus_user_a2.md)
+ [SUS02-BP02 Alinhar os SLAs com as metas de sustentabilidade](sus_sus_user_a3.md)
+ [SUS02-BP03 Interromper a criação e a manutenção de ativos não utilizados](sus_sus_user_a4.md)
+ [SUS02-BP04 Otimizar o posicionamento geográfico das workloads com base nos respectivos requisitos de rede](sus_sus_user_a5.md)
+ [SUS02-BP05 Otimizar os recursos dos membros da equipe para as atividades realizadas](sus_sus_user_a6.md)
+ [SUS02-BP06 Implementar armazenamento em buffer ou controle de utilização para nivelar a curva da demanda](sus_sus_user_a7.md)

# SUS02-BP01 Escalar a infraestrutura da workload dinamicamente
<a name="sus_sus_user_a2"></a>

Use a elasticidade da nuvem e escale sua infraestrutura de forma dinâmica para corresponder a oferta de recursos de nuvem à demanda e evitar capacidade superprovisionada em sua workload.

**Antipadrões comuns:**
+ Você não dimensiona sua infraestrutura de acordo com a carga de usuários.
+ Você dimensiona sua infraestrutura manualmente o tempo todo.
+ Você deixa a capacidade aumentada após um evento de escalabilidade, em vez de reduzir novamente.

 **Benefícios do estabelecimento dessa prática recomendada: **configurar e testar a elasticidade da workload ajuda a corresponder de maneira eficiente a oferta de recursos de nuvem à demanda e evitar a capacidade superprovisionada. Você pode aproveitar a elasticidade na nuvem para escalar automaticamente a capacidade durante e depois de picos de demanda para garantir que esteja usando apenas o número exato de recursos necessários para atender aos requisitos do seu negócio.

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 A nuvem fornece a flexibilidade de expandir ou reduzir seus recursos dinamicamente por meio de diversos mecanismos para atender a mudanças na demanda. O equilíbrio ideal entre a oferta e a demanda oferece o menor impacto ambiental para uma workload. 

 A demanda pode ser fixa ou variável, exigindo métricas e automação para garantir que o gerenciamento não se torne um gasto excessivo. Os aplicativos podem aumentar ou diminuir a escala verticalmente ao modificar o tamanho da instância e horizontalmente ao modificar o número de instâncias, ou uma combinação de ambos. 

 Você pode usar diversas abordagens diferentes para corresponder a oferta de recursos com a demanda. 
+  **Abordagem de monitoramento de meta:** monitore sua métrica de escalabilidade e aumente ou diminua automaticamente a capacidade conforme necessário. 
+  **Escalabilidade preditiva:** escale antecipadamente em relação às tendências diárias e semanais. 
+  **Abordagem com base na programação:** defina sua própria programação de escalabilidade de acordo com as alterações de carga previsíveis. 
+  **Escalabilidade de serviços:** escolha serviços (como tecnologia sem servidor) que são escalados nativamente por design ou fornecem escalabilidade automática como um recurso. 

 Identifique períodos de utilização baixa ou sem utilização e escale os recursos para eliminar a capacidade em excesso e melhorar a eficiência. 

## Etapas da implementação
<a name="implementation-steps"></a>
+ A elasticidade corresponde à oferta de recursos que você tem face à demanda por estes recursos. Instâncias, contêineres e funções fornecem mecanismos para elasticidade, seja em combinação com a escalabilidade automática ou como um recurso do serviço. A AWS fornece uma variedade de mecanismos de escalabilidade automática para garantir que as workloads possam reduzir a escala verticalmente de forma rápida e fácil durante períodos de baixa carga de usuário. Veja alguns exemplos de mecanismos de escalabilidade automática:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_user_a2.html)
+  A escalabilidade geralmente é discutida em relação a serviços de computação, como instâncias do Amazon EC2 ou funções do AWS Lambda. Considere a configuração de serviços não relacionados a computação, como o [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), e grave unidades de capacidade ou fragmentos do [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) para corresponder à demanda. 
+  Verifique se as métricas para aumentar ou reduzir a escala verticalmente são validadas em relação ao tipo de workload que está sendo implantada. Se você estiver implantando uma aplicação de transcodificação de vídeo, espera-se que a utilização da CPU seja de 100%, e essa não deve ser sua métrica principal. Você pode usar uma [métrica personalizada](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) (como utilização de memória) para a política de escalabilidade, se necessário. Para escolher as métricas certas, considere a seguinte orientação para o Amazon EC2: 
  +  A métrica deve ser uma métrica de utilização válida e descrever o quanto uma instância está ocupada. 
  +  O valor da métrica deve aumentar ou diminuir proporcionalmente com o número de instâncias no grupo do Auto Scaling. 
+  Use a [escalabilidade dinâmica](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html) em vez da [escalabilidade manual](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) para o seu grupo do Auto Scaling. Também recomendamos que você use as [políticas de escalabilidade de monitoramento de meta](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) na sua escalabilidade dinâmica. 
+  Verifique se as implantações da workload podem lidar com eventos de aumento e redução horizontal da escala. Crie cenários de teste para eventos de redução horizontal da escala para verificar se a workload se comporta conforme o esperado e não afeta a experiência do usuário (como perda da sessão persistente). Você também pode usar o [histórico de atividades](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html) para verificar a atividade de escalabilidade para um grupo do Auto Scaling. 
+  Avalie sua workload com relação a padrões previsíveis e, ao antecipar alterações previstas e planejadas na demanda, escale proativamente. Com a escalabilidade preditiva, é possível eliminar a necessidade de superprovisionar a capacidade. Para obter mais detalhes, consulte [Escalabilidade preditiva com o Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Conceitos básicos do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Escalabilidade preditiva para o EC2 com Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 
+  [Analisar o comportamento dos usuários usando o Amazon OpenSearch Service, o Amazon Data Firehose e o Kibana](https://aws.amazon.com/blogs/database/analyze-user-behavior-using-amazon-elasticsearch-service-amazon-kinesis-data-firehose-and-kibana/) 
+  [O que é o Amazon CloudWatch?](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html) 
+  [Monitorar a carga do banco de dados com o Performance Insights no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 
+  [Introdução ao suporte nativo para escalabilidade preditiva com o Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/) 
+  [Apresentando o Karpenter: um dimensionador automático de clusters do Kubernetes de código aberto e alta performance](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/) 
+  [Aprofundamento do Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/) 

 **Vídeos relacionados:** 
+  [Build a cost-, energy-, and resource-efficient compute environment](https://www.youtube.com/watch?v=8zsC5e1eLCg) (Criar um ambiente de computação eficiente em termos de custo, energia e recursos) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) (Computação melhor, mais rápida e mais barata: otimização de custos com o Amazon EC2) 

 **Exemplos relacionados:** 
+  [Laboratório: Exemplos de grupos do Amazon EC2 Auto Scaling](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) 
+  [Laboratório: Implementação de escalabilidade automática com o Karpenter](https://www.eksworkshop.com/beginner/085_scaling_karpenter/) 

# SUS02-BP02 Alinhar os SLAs com as metas de sustentabilidade
<a name="sus_sus_user_a3"></a>

 Analise e otimize os Acordos de Serviço (SLA) com base em suas metas de sustentabilidade para minimizar os recursos necessários a fim de oferecer compatibilidade com sua workload enquanto continua a atender às necessidades empresariais. 

 **Antipadrões comuns:** 
+  SLAs de workload são desconhecidos ou ambíguos. 
+  Você define seu SLA apenas para disponibilidade e performance. 
+  Você usa o mesmo padrão de design (como arquitetura multi-AZ) para todas as suas workloads. 

 **Benefícios do estabelecimento desta prática recomendada:** o alinhamento dos SLAs com as metas de sustentabilidade ocasiona o uso ideal dos recursos e a concretização das necessidades empresariais. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Os SLAs definem o nível de serviço esperado de uma workload de nuvem, como tempo de resposta, disponibilidade e retenção de dados. Eles influenciam a arquitetura, o uso de recursos e o impacto ambiental de uma workload de nuvem. Em uma cadência regular, analise os SLAs e faça compensações que reduzam significativamente o uso de recursos em troca de reduções aceitáveis em níveis de serviço. 

 **Etapas da implementação** 
+  Defina ou remodele SLAs que apoiem suas metas de sustentabilidade e, ao mesmo tempo, atendam aos seus requisitos empresariais, não os excedendo. 
+  Faça compensações que reduzam significativamente os impactos na sustentabilidade em troca de reduções aceitáveis em níveis de serviço. 
  +  **Sustentabilidade e confiabilidade:** workloads altamente disponíveis tendem a consumir mais recursos. 
  +  **Sustentabilidade e performance:** o uso de mais recursos para impulsionar a performance pode causar um maior impacto ambiental. 
  +  **Sustentabilidade e segurança:** workloads excessivamente seguras podem ter um maior impacto ambiental. 
+  Use padrões de design, como [microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html) que priorizem funções essenciais aos negócios e permita níveis de serviço mais baixos (como objetivos de tempo de resposta ou de tempo de recuperação) para funções não essenciais. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Acordos de nível de serviço da AWS (SLAs)](https://aws.amazon.com/legal/service-level-agreements/?aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all) 
+  [Importance of Service Level Agreement for SaaS Providers](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/) 

 **Vídeos relacionados:** 
+ [ Delivering sustainable, high-performing architectures ](https://www.youtube.com/watch?v=FBc9hXQfat0) (Entregar arquiteturas sustentáveis e de alta performance)
+ [Criar um ambiente de computação eficiente em termos de custo, energia e recursos](https://www.youtube.com/watch?v=8zsC5e1eLCg)

# SUS02-BP03 Interromper a criação e a manutenção de ativos não utilizados
<a name="sus_sus_user_a4"></a>

Desative ativos em sua workload para reduzir o número de recursos necessários para atender à sua demanda e minimizar o desperdício.

 **Antipadrões comuns:** 
+  Você não analisa sua aplicação com relação a ativos redundantes ou não mais necessários. 
+  Você não remove ativos redundantes ou não mais necessários. 

 **Benefícios do estabelecimento desta prática recomendada:** a remoção de ativos ociosos libera recursos e melhora a eficiência geral da workload. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Os ativos ociosos consomem recursos de nuvem como espaço de armazenamento e potência computacional. Com a identificação e eliminação desses ativos, você pode liberar esses recursos e aumentar a eficiência da arquitetura de nuvem. Analise regularmente os ativos de aplicações (como relatórios pré-compilados, conjuntos de dados e imagens estáticas) e os padrões de acesso aos ativos para identificar redundâncias, subutilização e possíveis alvos de desativação. Remova esses ativos redundantes para diminuir o desperdício de recursos em sua workload. 

 **Etapas da implementação** 
+  Use ferramentas de monitoramento para identificar ativos estáticos que não são mais necessários. 
+  Antes de remover qualquer ativo, avalie o impacto da remoção sobre a arquitetura. 
+  Desenvolva um plano e remova os ativos que não são mais necessários. 
+  Consolide ativos gerados sobrepostos para remover o processamento redundante. 
+  Atualize suas aplicações para que não produzam nem armazenem mais ativos que não são necessários. 
+  Instrua terceiros a interromper a produção e o armazenamento de ativos gerenciados em seu nome que não sejam mais necessários. 
+  Instrua terceiros a consolidar ativos redundantes produzidos em seu nome. 
+  Avalie regularmente sua workload para identificar e remover ativos ociosos. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Otimizar a sua infraestrutura da AWS para sustentabilidade, Parte II: Armazenamento](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/) 
+ [ Como faço para verificar se há recursos ativos dos quais não preciso mais na minha Conta da AWS? ](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-resources-account-closure/)

 **Vídeos relacionados:** 
+ [ Como verifico e depois removo recursos ativos dos quais não preciso mais na minha Conta da AWS? ](https://www.youtube.com/watch?v=pqg9AqESRlg)

# SUS02-BP04 Otimizar o posicionamento geográfico das workloads com base nos respectivos requisitos de rede
<a name="sus_sus_user_a5"></a>

Selecione locais e serviços de nuvem para sua workload que reduzam a distância que o tráfego de rede deve percorrer e diminua o total de recursos de rede necessários para comportar a workload.

 ** Antipadrões comuns: ** 
+  Selecione a região da workload com base em sua localização. 
+  Você consolida todos os recursos da workload em uma única localização geográfica. 
+  Todo o tráfego flui por meio dos datacenters existentes. 

 **Benefícios de estabelecer esta prática recomendada:** Implantar uma workload perto dos clientes proporciona a latência mais baixa enquanto reduz a movimentação de dados pela rede e reduz o impacto ambiental. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A infraestrutura da Nuvem AWS é construída em torno de opções de local, como regiões, zonas de disponibilidade, grupos de posicionamento e locais da borda, como [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) e [zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). Essas opções de local são responsáveis por manter a conectividade entre componentes da aplicação, serviços de nuvem, redes da borda e datacenters on-premises. 

 Analise os padrões de acesso à rede em sua workload para identificar como usar essas opções de local de nuvem e reduzir a distância que o tráfego de rede precisa percorrer. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Analise os padrões de acesso à rede em sua workload para identificar como os usuários utilizam sua aplicação. 
  +  Use ferramentas de monitoramento, como [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) e o [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), para coletar dados sobre as atividades da rede. 
  +  Analise os dados para identificar o padrão de acesso à rede. 
+  Selecione as regiões para implantação da workload com base nos seguintes elementos fundamentais: 
  +  **Sua meta de sustentabilidade:** conforme explicado em [Seleção de região](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html). 
  +  **A localização dos seus dados:** para aplicações com uso intenso de dados (como big data e machine learning), o código da aplicação deve ser executado o mais perto possível dos dados. 
  +  **A localização dos usuários:** para aplicações voltadas ao usuário, escolha uma região (ou regiões) próxima dos clientes de sua workload.
  + **Outras restrições:** Leve em conta restrições, como custo e conformidade, conforme explicado em [O que considerar ao selecionar uma região para suas workloads](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/).
+  Use armazenamento em cache local ou [soluções de armazenamento em cache da AWS](https://aws.amazon.com/caching/aws-caching/) para ativos usados com frequência a fim de aumentar a performance, reduzir a movimentação de dados e reduzir o impacto ambiental.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_user_a5.html)
+  Use serviços que podem ajudar você a executar código mais perto dos usuários da workload:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_user_a5.html)
+  Use o agrupamento de conexões para permitir a reutilização de conexões e reduzir os recursos necessários. 
+  Use datastores distribuídos que não dependem de conexões persistentes e atualizações síncronas para fins de consistência com o objetivo de atender a populações regionais. 
+  Substitua a capacidade de rede estática pré-provisionada por capacidade dinâmica compartilhada e divida o impacto sobre a sustentabilidade da capacidade de rede com outros assinantes. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Otimizar a sua infraestrutura da AWS para sustentabilidade, Parte III: Redes](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/) 
+  [Documentação do Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/index.html) 
+  [O que é o Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 
+  [Principais recursos do Amazon CloudFront](https://aws.amazon.com/cloudfront/features/) 

 **Vídeos relacionados:** 
+  [Demystifying data transfer on AWS (Desmistificação da transferência de dados na AWS)](https://www.youtube.com/watch?v=-MqXgzw1IGA) 
+ [ Escalar a performance da rede em instâncias do Amazon EC2 de última geração ](https://www.youtube.com/watch?v=jNYpWa7gf1A)

 **Exemplos relacionados:** 
+  [Workshops de redes da AWS](https://catalog.workshops.aws/networking/en-US) 
+ [ Arquitetura para a sustentabilidade: reduza a movimentação de dados entre redes ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)

# SUS02-BP05 Otimizar os recursos dos membros da equipe para as atividades realizadas
<a name="sus_sus_user_a6"></a>

Otimize os recursos fornecidos aos membros da equipe para minimizar o impacto sobre a sustentabilidade ambiental e, ao mesmo tempo, atender às suas necessidades. 

 **Antipadrões comuns:** 
+  Você ignora o impacto dos dispositivos usados pelos membros da equipe sobre a eficiência geral de sua aplicação de nuvem. 
+  Você gerencia e atualiza manualmente os recursos usados pelos membros da equipe. 

 **Benefícios do estabelecimento desta prática recomendada:** otimizar recursos para os membros da equipe melhora a eficiência geral das aplicações habilitadas para a nuvem. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Conheça os recursos que os membros da equipe usam para consumir seus serviços, o ciclo de vida esperado e o impacto financeiro e na sustentabilidade. Implemente estratégias para otimizar esses recursos. Por exemplo, realize operações complexas, como renderização e compilação, em infraestrutura escalável com alta utilização em vez de em sistemas de usuário único subutilizados com alto consumo de energia. 

 **Etapas da implementação** 
+  Provisione estações de trabalho e outros dispositivos para alinhar a maneira como eles são usados. 
+  Use áreas de trabalho virtuais e a transmissão de aplicações para limitar os requisitos de upgrade e dispositivos. 
+  Migre para a nuvem as tarefas do processador e as com uso intenso de memória a fim de utilizar a respectiva elasticidade. 
+  Avalie o impacto de processos e sistemas no ciclo de vida de seus dispositivos e escolha soluções que minimizem o requisito de substituição de dispositivos e, ao mesmo tempo, atendam aos requisitos empresariais. 
+  Implemente o gerenciamento remoto de dispositivos para reduzir as viagens de negócios. 
  +  O [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html) é uma experiência de interface do usuário (UI) que ajuda você a gerenciar remotamente os nós em execução na AWS ou no ambiente on-premises. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [O que é o Amazon WorkSpaces?](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html) 
+ [ Otimizador de custos para o Amazon WorkSpaces ](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/overview.html)
+  [Documentação do Amazon AppStream 2.0](https://docs.aws.amazon.com/appstream2/) 
+  [NICE DCV](https://docs.aws.amazon.com/dcv/) 

 **Vídeos relacionados:** 
+  [Gerenciamento de custos do Amazon WorkSpaces na AWS](https://www.youtube.com/watch?v=0MoY31hZQuE) 

# SUS02-BP06 Implementar armazenamento em buffer ou controle de utilização para nivelar a curva da demanda
<a name="sus_sus_user_a7"></a>

O armazenamento em buffer e o controle de utilização nivelam a curva da demanda e reduzem a capacidade provisionada necessária para sua workload. 

 **Antipadrões comuns:** 
+ Você processa imediatamente as solicitações de cliente embora isso não seja necessário.
+ Você não analisa os requisitos das solicitações de cliente.

 **Benefícios do estabelecimento desta prática recomendada:** nivelar a curva da demanda reduz a capacidade provisionada necessária para a workload. Reduzir a capacidade provisionada significa diminuir o consumo de energia e o impacto ambiental. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

 Nivelar a curva da demanda pode ajudar você a reduzir a capacidade provisionada para uma workload e a diminuir o respectivo impacto ambiental. Considere a workload com a curva de demanda mostrada na figura a seguir. Essa workload tem dois picos e, para lidar com eles, é provisionada a capacidade de recurso mostrada pela linha laranja. Os recursos e energia usados para essa workload não são indicados pela área abaixo da curva da demanda, mas pela área abaixo da linha da capacidade provisionada, visto que é preciso ter capacidade provisionada para lidar com esses dois picos. 

![\[Forma de onda da capacidade provisionada com dois picos distintos que exigem alta capacidade provisionada.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/provisioned-capacity-1.png)


 

 Você pode usar o armazenamento em buffer ou o controle de utilização para modificar a curva da demanda e atenuar os picos, o que significa menor capacidade provisionada e menor consumo de energia. Implemente o controle de utilização quando seus clientes puderem realizar novas tentativas. Implemente o armazenamento em buffer para armazenar a solicitação e adiar o processamento até um momento posterior. 

![\[Diagrama de forma de onda exibindo uma workload com picos atenuados por meio do armazenamento em buffer e do controle de utilização.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/provisioned-capacity-2.png)


 

 **Etapas da implementação** 
+  Analise as solicitações dos clientes para determinar como responder a elas. As perguntas a serem consideradas incluem: 
  +  Essa solicitação pode ser processada assincronamente? 
  +  O cliente tem capacidade de repetição? 
+  Se o cliente tiver capacidade de repetição, você pode implementar o controle de utilização, que informa à origem que, se ela não puder atender à solicitação naquele momento, deverá tentar novamente mais tarde. 
  +  Você pode usar o [Amazon API Gateway](https://aws.amazon.com/api-gateway/) para implementar o controle de utilização. 
+  Para clientes que não podem realizar novas tentativas, é necessário implementar um buffer para nivelar a curva da demanda. O buffer adia o processamento de solicitações, permitindo que as aplicações executadas em diferentes taxas se comuniquem com eficácia. Uma abordagem baseada em buffer usa uma fila ou um fluxo para aceitar mensagens de produtores. As mensagens são lidas pelos consumidores e processadas, permitindo que as mensagens sejam executadas na taxa que atenda aos requisitos de negócios dos consumidores. 
  +  O [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) é um serviço gerenciado que fornece filas que permitem que um único consumidor leia mensagens individuais. 
  +  O [Amazon Kinesis](https://aws.amazon.com/kinesis/) oferece um fluxo que permite que vários consumidores leiam as mesmas mensagens. 
+  Analise a demanda geral, a taxa de alteração e o tempo de resposta necessário para dimensionar adequadamente o controle ou buffer necessário. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Conceitos básicos do Amazon SQS ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [ Integração de aplicações usando filas e mensagens ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)

 **Vídeos relacionados:** 
+ [ Escolha do serviço de mensagem correto para sua aplicação distribuída ](https://www.youtube.com/watch?v=4-JmX6MIDDI)

# Software e arquitetura
<a name="a-sus-software-architecture"></a>

**Topics**
+ [SUS 3 Como aproveitar os padrões de software e arquitetura para apoiar as metas de sustentabilidade?](sus-03.md)

# SUS 3 Como aproveitar os padrões de software e arquitetura para apoiar as metas de sustentabilidade?
<a name="sus-03"></a>

Implemente padrões que suavizem os picos de carga e mantenham a alta utilização consistente de recursos implantados para minimizar os recursos consumidos. Os componentes podem ficar ociosos devido à falta de uso por conta das mudanças no comportamento do usuário ao longo do tempo. Revise os padrões e a arquitetura para consolidar os componentes subutilizados a fim de aumentar a utilização geral. Retire os componentes que não são mais necessários. Saiba qual é a performance dos componentes de sua workload e otimize os componentes que consomem a maioria dos recursos. Esteja ciente dos dispositivos que seus clientes usam para acessar seus serviços e implemente padrões a fim de minimizar a necessidade de upgrades de dispositivos. 

**Topics**
+ [SUS03-BP01 Otimizar o software e a arquitetura para trabalhos assíncronos e programados](sus_sus_software_a2.md)
+ [SUS03-BP02 Remover ou refatorar componentes da workload subutilizados ou não utilizados](sus_sus_software_a3.md)
+ [SUS03-BP03 Otimizar as áreas de código que consomem mais tempo ou recursos](sus_sus_software_a4.md)
+ [SUS03-BP04 Otimizar o impacto sobre dispositivos e equipamentos](sus_sus_software_a5.md)
+ [SUS03-BP05 Usar arquiteturas e padrões de software que atendam melhor aos padrões de armazenamento e acesso aos dados](sus_sus_software_a6.md)

# SUS03-BP01 Otimizar o software e a arquitetura para trabalhos assíncronos e programados
<a name="sus_sus_software_a2"></a>

Use software eficiente e padrões de arquitetura, como orientado a filas, para manter uma alta e consistente utilização dos recursos implantados.

 **Antipadrões comuns:** 
+  Provisione em excesso os recursos em sua workload na nuvem para atender a picos imprevistos na demanda. 
+  Sua arquitetura não separa remetentes e destinatários de mensagens assíncronas por um componente de sistema de mensagens. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Padrões eficientes de software e arquitetura minimizam os recursos não utilizados em sua workload e melhoram a eficiência geral. 
+  Você pode dimensionar o processamento independentemente do recebimento de mensagens assíncronas. 
+  Por meio de um componente de mensagens, você relaxou os requisitos de disponibilidade que podem ser atendidos com menos recursos. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Use padrões de arquitetura eficientes, como [arquitetura orientada por eventos](https://aws.amazon.com/event-driven-architecture/), que resultam na utilização uniforme de componentes e minimizam o provisionamento em excesso em sua workload. A utilização de padrões de arquitetura eficientes minimiza recursos ociosos por falta de uso devido a mudanças na demanda ao longo do tempo. 

 Entenda os requisitos de seus componentes de workload e adote padrões de arquitetura que aumentam a utilização geral dos recursos. Retire os componentes que não são mais necessários. 

 **Etapas da implementação** 
+  Analise a demanda de sua workload para determinar como responder a ela. 
+  Para solicitações ou trabalhos que não exigem respostas síncronas, use arquiteturas orientadas por filas e operadores de escalonamento automático para maximizar a utilização. Aqui estão alguns exemplos de quando você pode considerar a arquitetura orientada por filas:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_software_a2.html)
+  Para solicitações ou trabalhos que podem ser processados a qualquer momento, use mecanismos de agendamento para processar trabalhos em lote para maior eficiência. Aqui estão alguns exemplos de mecanismos de agendamento no AWS:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_software_a2.html)
+  Se você usar mecanismos de pesquisa e webhooks em sua arquitetura, substitua-os por eventos. Use [arquiteturas orientadas por eventos](https://docs.aws.amazon.com/lambda/latest/operatorguide/event-driven-architectures.html) para criar workloads altamente eficientes. 
+  Aproveite a [a computação sem servidor no AWS](https://aws.amazon.com/serverless/) para eliminar a infraestrutura provisionada em excesso. 
+  Dimensione corretamente componentes individuais de sua arquitetura para evitar recursos ociosos aguardando entrada. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [O que é o Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) 
+  [O que é o Amazon MQ?](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) 
+  [Escalabilidade baseada no Amazon SQS](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html) 
+  [O que é o AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 
+  [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 
+  [Usando o AWS Lambda com o Amazon SQS](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html) 
+  [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 

 **Vídeos relacionados:** 
+  [Moving to event-driven architectures (Mudando para arquiteturas orientadas a eventos)](https://www.youtube.com/watch?v=h46IquqjF3E) 

# SUS03-BP02 Remover ou refatorar componentes da workload subutilizados ou não utilizados
<a name="sus_sus_software_a3"></a>

Remova os componentes que não são mais utilizados nem necessários e refatore os componentes pouco usados para minimizar o desperdício em sua workload.

 **Antipadrões comuns:** 
+  Você não verifica regularmente o nível de utilização de componentes individuais de sua workload. 
+  Você não verifica nem analisa as recomendações de ferramentas de dimensionamento correto da AWS, como o [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/). 

 **Benefícios do estabelecimento desta prática recomendada:** a remoção de ativos ociosos minimiza o desperdício e melhorar a eficiência geral da workload de nuvem. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Avalie sua workload para identificar componentes ociosos ou não utilizados. Esse é um processo de melhoria interativo que pode ser acionado por alterações na demanda ou pelo lançamento de um novo serviço de nuvem. Por exemplo, uma queda significativa no tempo de execução da função do [AWS Lambda](https://docs.aws.amazon.com/lambda/) pode ser uma indicação de que é necessário reduzir o tamanho da memória. Além disso, à medida que a AWS lança novos serviços e recursos, a arquitetura e os serviços ideais para sua workload podem mudar. 

 Monitore continuamente a atividade da workload e procure oportunidades para melhorar o nível de utilização de componentes individuais. Com a remoção de componentes ociosos e a execução de atividades de dimensionamento correto, você atende aos seus requisitos empresariais com menos recursos de nuvem. 

 **Etapas da implementação** 
+  Monitore e capture métricas de utiliza de componentes essenciais de sua workload (como utilização de CPU, utilização de memória ou throughput de rede nas [métricas do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)). 
+  Para workloads estáveis, confira regularmente as ferramentas de dimensionamento correto da AWS, como o [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/), para identificar componentes ociosos, não usados ou subutilizados. 
+  Para workloads efêmeras, avalie as métricas de utilização para identificar componentes ociosos, não usados ou subutilizados. 
+  Retire componentes e ativos associados (como imagens do Amazon ECR) que não são mais necessários. 
+  Refatore ou consolide os componentes subutilizados com outros recursos para melhorar a eficiência da utilização. Por exemplo, você pode provisionar vários bancos de dados pequenos em uma única instância de banco de dados do [Amazon RDS](https://aws.amazon.com/rds/), em vez de executar bancos de dados em instâncias individuais subutilizadas. 
+  Saiba quais [recursos são provisionados por sua workload para concluir uma unidade de trabalho](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/evaluate-specific-improvements.html). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+  [O que é o Amazon CloudWatch?](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html) 
+  [Limpeza automatizada de imagens não utilizadas no Amazon ECR](https://aws.amazon.com/blogs/compute/automated-cleanup-of-unused-images-in-amazon-ecr/) 

 **Exemplos relacionados:** 
+ [ Laboratório do Well-Architected: Dimensionamento correto com o AWS Compute Optimizer](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [ Laboratório do Well-Architected: Otimizar padrões de hardware e observar KPIs de sustentabilidade ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)

# SUS03-BP03 Otimizar as áreas de código que consomem mais tempo ou recursos
<a name="sus_sus_software_a4"></a>

Otimize o código que é executado em diferentes componentes de sua arquitetura para minimizar o uso de recursos e, ao mesmo tempo, maximizar a performance.

 **Antipadrões comuns:** 
+  Você ignora a otimização de seu código para uso de recursos. 
+  Normalmente, você responde a problemas de performance aumentando os recursos. 
+  Seu processo de revisão e desenvolvimento de código não monitora alterações na performance. 

 **Benefícios de estabelecer esta prática recomendada:** O uso de código eficiente minimiza o uso de recursos e melhora a performance. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 É essencial examinar toda área funcional, incluindo o código referente a uma aplicação projetada para a nuvem, para otimizar o uso de recursos e a performance. Monitore continuamente a performance da workload em ambientes de compilação e na produção e identifique oportunidades para melhorar os trechos cujo uso de recursos é particularmente alto. Adote um processo de revisão regular para identificar erros ou antipadrões dentro do código que usa os recursos ineficazmente. Utilize algoritmos simples e eficientes que produzem os mesmos resultados para seu caso de uso. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Ao desenvolver suas workloads, adote um processo de revisão de código automatizada para melhorar a qualidade e identificar erros e antipadrões. 
  + [ Análises de código automatizadas com o Amazon CodeGuru Reviewer ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
  + [ Detecção de erros simultâneos com o Amazon CodeGuru ](https://aws.amazon.com/blogs/devops/detecting-concurrency-bugs-with-amazon-codeguru/)
  + [ Elevação da qualidade do código para aplicações Python usando o Amazon CodeGuru ](https://aws.amazon.com/blogs/devops/raising-code-quality-for-python-applications-using-amazon-codeguru/)
+  À medida que você executa suas workloads, monitore os recursos para identificar componentes com altos requisitos de recurso por unidade de trabalho como alvos para revisões de código. 
+  Para revisões de código, use um criador de perfil de código para identificar as áreas de código que gastam mais tempo ou usam mais recursos e as defina como alvos de otimização. 
  + [ Reduzir a pegada de carbono de sua organização com o Amazon CodeGuru Profiler ](https://aws.amazon.com/blogs/devops/reducing-your-organizations-carbon-footprint-with-codeguru-profiler/)
  + [ Conceitos básicos sobre o uso de memória em sua aplicação Java com o Amazon CodeGuru Profiler ](https://aws.amazon.com/blogs/devops/understanding-memory-usage-in-your-java-application-with-amazon-codeguru-profiler/)
  + [ Melhorar a experiência do cliente e reduzir os custos com o Amazon CodeGuru Profiler ](https://aws.amazon.com/blogs/devops/improving-customer-experience-and-reducing-cost-with-codeguru-profiler/)
+  Use a linguagem de programação e o sistema operacional mais eficientes para a workload. Para obter detalhes sobre linguagens de programação com eficiência energética (incluindo Rust), consulte [Sustentabilidade com Rust](https://aws.amazon.com/blogs/opensource/sustainability-with-rust/). 
+  Substitua os algoritmos com uso intenso de computação por uma versão mais simples e mais eficiente que produza o mesmo resultado. 
+  Remova códigos desnecessários, como classificações e formatações. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [O que é o Amazon CodeGuru Profiler?](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html) 
+  [Instâncias de FPGA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/fpga-getting-started.html) 
+  [Os AWS SDKs em Ferramentas para desenvolver na AWS](https://aws.amazon.com/tools/) 

 **Vídeos relacionados:** 
+ [ Improve Code Efficiency Using Amazon CodeGuru Profiler (Como melhorar a eficiência do código usando o Amazon CodeGuru Profiler) ](https://www.youtube.com/watch?v=1pU4VddsBRw)
+ [ Automate Code Reviews and Application Performance Recommendations with Amazon CodeGuru (Como automatizar revisões de código e recomendações de performance de aplicação com o Amazon CodeGuru) ](https://www.youtube.com/watch?v=OD8H63C0E0I)

# SUS03-BP04 Otimizar o impacto sobre dispositivos e equipamentos
<a name="sus_sus_software_a5"></a>

Conheça os dispositivos e equipamentos usados em sua arquitetura e use estratégias para reduzir o respectivo uso. Isso pode minimizar o impacto ambiental de modo geral de sua workload de nuvem. 

 **Antipadrões comuns:** 
+  Você ignora o impacto ambiental dos dispositivos usados por seus clientes. 
+  Você gerencia e atualiza manualmente os recursos usados pelos clientes. 

 **Benefícios do estabelecimento desta prática recomendada:** implementar padrões e recursos de software que são otimizados para o dispositivo do cliente pode reduzir o impacto ambiental de modo geral da workload de nuvem. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Implementar padrões e recursos de software que são otimizados para os dispositivos do clientes pode reduzir o impacto ambiental de variadas maneiras: 
+  Implementar novos recursos que são compatíveis com versões anteriores pode reduzir o número de substituições de hardware. 
+  Otimizar uma aplicação para ser executada com eficiência nos dispositivos pode ajudar a reduzir o consumo de energia e a estender a duração da bateria (se eles forem alimentados por bateria). 
+  Otimizar uma aplicação para dispositivos também pode reduzir a transferência de dados ao longo da rede. 

 Conheça os dispositivos e equipamentos usados em sua arquitetura, o ciclo de vida esperado e o impacto da substituição desses componentes. Implemente padrões e recursos de software que possam ajudar a minimizar o consumo de energia do dispositivo, bem como a necessidade de os clientes substituírem o dispositivo e também atualizá-lo manualmente. 

 **Etapas da implementação** 
+  Faça um inventário dos dispositivos usados em sua arquitetura. Os dispositivos podem ser celular, tablet, dispositivos IoT, lâmpada inteligente ou até dispositivos inteligentes em uma fábrica. 
+  Otimize a aplicação executada nos dispositivos: 
  +  Use estratégias como execução de tarefas em segundo plano para reduzir o consumo de energia. 
  +  Considere a largura de banda da rede e a latência ao criar cargas úteis, e implemente recursos que ajudem suas aplicações a funcionar bem em links de baixa largura de banda e alta latência. 
  +  Converta cargas úteis e arquivos nos formatos otimizados exigidos pelos dispositivos. Por exemplo, você pode usar o [Amazon Elastic Transcoder](https://docs.aws.amazon.com/elastic-transcoder/) ou o [AWS Elemental MediaConvert](https://aws.amazon.com/mediaconvert/) para converter arquivos de mídia digital grandes e de alta qualidade em formatos que os usuários possam reproduzir em dispositivos móveis, tablets, navegadores Web e televisores conectados. 
  +  Realize atividades com computação intensa no lado do servidor (como renderização de imagens) ou use a transmissão de aplicações para melhorar a experiência do usuário em dispositivos mais antigos. 
  +  Faça a segmentação e a paginação dos dados de saída, especialmente para sessões interativas, a fim de gerenciar cargas úteis e limitar os requisitos de armazenamento local. 
+  Use um mecanismo sem fio automatizado para implantar atualizações em um ou mais dispositivos. 
  +  Você pode usar um [pipeline de CI/CD](https://aws.amazon.com/blogs/mobile/build-a-cicd-pipeline-for-your-android-app-with-aws-services/) para atualizar aplicativos móveis. 
  +  Você pode usar o [AWS IoT Device Management](https://aws.amazon.com/iot-device-management/) para gerenciar remotamente dispositivos conectados em escala. 
+  Para testar novos recursos e atualizações, use parques de dispositivos gerenciados com conjuntos representativos de hardware e itere o desenvolvimento para maximizar os dispositivos compatíveis. Para obter mais detalhes, consulte [SUS06-BP04 Usar parques de dispositivos gerenciados para testes](sus_sus_dev_a5.md). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [O que é o AWS Device Farm?](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) 
+  [Documentação do Amazon AppStream 2.0](https://docs.aws.amazon.com/appstream2/) 
+  [NICE DCV](https://docs.aws.amazon.com/dcv/) 
+ [ Tutorial de OTA para atualização de firmware em dispositivos que executam o FreeRTOS ](https://docs.aws.amazon.com/freertos/latest/userguide/dev-guide-ota-workflow.html)

 **Vídeos relacionados:** 
+ [ Introdução ao AWS Device Farm](https://www.youtube.com/watch?v=UiJo_PEZkD4)

# SUS03-BP05 Usar arquiteturas e padrões de software que atendam melhor aos padrões de armazenamento e acesso aos dados
<a name="sus_sus_software_a6"></a>

Entenda como os dados são usados com sua workload, consumidos pelos usuários, transferidos e armazenados. Use os padrões e arquiteturas de software ideais para acesso e armazenamento de dados a fim de minimizar os recursos de computação, rede e armazenamento necessários para atender à workload.

 **Antipadrões comuns:** 
+  Você pressupõe que todas as workloads têm padrões de acesso e armazenamento de dados semelhantes. 
+  Você usa apenas um nível de armazenamento, supondo que todas as workloads se encaixem nesse nível. 
+  Você pressupõe que os padrões de acesso aos dados permanecerão consistentes ao longo do tempo. 
+  Na eventualidade de uma alta expansão no acesso aos dados, sua arquitetura é capaz de comportá-la, mas isso faz com que os recursos fiquem ociosos na maior parte do tempo. 

 **Benefícios do estabelecimento desta prática recomendada:** selecionar e otimizar sua arquitetura com base nos padrões de acesso e armazenamento de dados ajudará a diminuir a complexidade do desenvolvimento e a aumentar a utilização de modo geral. Compreender quando usar tabelas globais, provisionamento de dados e armazenamento em cache ajuda a reduzir a despesas operacionais indiretas e a escalar com base nas necessidades da workload. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Use padrões de software e arquitetura que melhor se alinhem às características dos dados e aos padrões de acesso. Por exemplo, use uma [arquitetura de dados moderna na AWS](https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/) que permita que você use serviços com propósito específico otimizados para seus casos de uso exclusivos de análise. Esses padrões de arquitetura possibilitam um processamento de dados eficiente e reduzem o uso de recursos. 

 **Etapas da implementação** 
+  Analise as características dos dados e os padrões de acesso para identificar a configuração correta para seus recursos de nuvem. Principais características a serem consideradas: 
  +  **Tipo de dados:** estruturados, semiestruturados e não estruturados 
  +  **Crescimento dos dados:** delimitado, não delimitado 
  +  **Durabilidade dos dados:** persistentes, efêmeros, transitórios 
  +  **Padrões de acesso:** leituras ou gravações, frequência de atualização, com picos ou consistente 
+  Use padrões de arquitetura que comportem melhor os padrões de armazenamento e acesso aos dados. 
  + [ Vamos arquitetar\$1 Arquiteturas de dados modernas ](https://aws.amazon.com/blogs/architecture/lets-architect-modern-data-architectures/)
  + [ Bancos de dados na AWS: a ferramenta certa para o trabalho certo ](https://www.youtube.com/watch?v=-pb-DkD6cWg)
+  Use tecnologias que funcionam nativamente com dados compactados. 
+  Use [serviços de análise](https://aws.amazon.com/big-data/datalakes-and-analytics/?nc2=h_ql_prod_an_a) com propósito específico para processamento de dados em sua arquitetura. 
+  Use o mecanismo de banco de dados que melhor comporta seu padrão de consulta dominante. Gerencie seus índices de bancos de dados para garantir a execução eficiente de consultas. Para ter mais detalhes, consulte [Bancos de dados da AWS](https://aws.amazon.com/products/databases/). 
+  Escolha protocolos de rede que reduzam a quantidade de capacidade de rede consumida em sua arquitetura. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Suporte a compactação no Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html) 
+  [COPY de formatos de dados colunar com o Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/copy-usage_notes-copy-from-columnar.html) 
+  [Converter o formato de registro de entrada no Firehose](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html) 
+  [Opções de formato de dados para entradas e saídas no AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html) 
+  [Melhorar a performance de consultas no Amazon Athena com a conversão em formatos colunares](https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.html) 
+  [Carregar arquivos de dados compactados do Amazon S3 com o Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html) 
+  [Monitorar a carga de banco de dados com o Performance Insights no Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 
+  [Monitorar a carga de banco de dados com o Performance Insights no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 
+ [ Classe de armazenamento do Amazon S3 Intelligent-Tiering ](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/)

 **Vídeos relacionados:** 
+ [ Criar arquiteturas modernas de dados na AWS](https://www.youtube.com/watch?v=Uk2CqEt5f0o)

# Dados
<a name="a-sus-data"></a>

**Topics**
+ [SUS 4 Como aproveitar as políticas e os padrões de gerenciamento de dados para apoiar as metas de sustentabilidade?](sus-04.md)

# SUS 4 Como aproveitar as políticas e os padrões de gerenciamento de dados para apoiar as metas de sustentabilidade?
<a name="sus-04"></a>

Implemente práticas de gerenciamento de dados para reduzir o armazenamento provisionado necessário para comportar a workload e os recursos exigidos para usá-la. Entenda seus dados e use as tecnologias e as configurações de armazenamento que promovam o valor empresarial dos dados de forma mais eficaz e a forma como eles são usados. Gerencie o ciclo de vida dos dados e opte por um armazenamento mais eficiente e com menor performance quando os requisitos diminuírem, excluindo os dados que não são mais necessários. 

**Topics**
+ [SUS04-BP01 Implementar uma política de classificação de dados](sus_sus_data_a2.md)
+ [SUS04-BP02 Usar tecnologias compatíveis com seus padrões de acesso e de armazenamento de dados](sus_sus_data_a3.md)
+ [SUS04-BP03 Usar políticas para gerenciar o ciclo de vida de seus conjuntos de dados](sus_sus_data_a4.md)
+ [SUS04-BP04 Usar elasticidade e automação para expandir o armazenamento em bloco ou o sistema de arquivos](sus_sus_data_a5.md)
+ [SUS04-BP05 Remover dados desnecessários ou redundantes](sus_sus_data_a6.md)
+ [SUS04-BP06 Usar sistemas de arquivos compartilhados ou armazenamento para acessar dados comuns](sus_sus_data_a7.md)
+ [SUS04-BP07 Minimizar a movimentação de dados entre redes](sus_sus_data_a8.md)
+ [SUS04-BP08 Fazer backup de dados somente quando for difícil recriar](sus_sus_data_a9.md)

# SUS04-BP01 Implementar uma política de classificação de dados
<a name="sus_sus_data_a2"></a>

Classifique os dados para entender sua importância para os resultados empresariais e selecione o nível de armazenamento eficiente em termos de energia para armazenar os dados.

 **Antipadrões comuns:** 
+  Você não identifica ativos de dados com características semelhantes (como sensibilidade, importância empresarial ou requisitos regulatórios) que estão sendo processados ou armazenados. 
+  Você não implementou um catálogo de dados para criar um inventário de seus ativos de dados. 

 **Benefícios do estabelecimento desta prática recomendada:** a implementação de uma política de classificação de dados permite determinar o nível de armazenamento eficiente em termos de energia para os dados. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 A classificação de dados envolve a identificação dos tipos de dados que estão sendo processados e armazenados em um sistema de informação pertencente a uma organização ou operado por ela. Também envolve a decisão em relação à importância dos dados e ao impacto provável do comprometimento dos dados, perda ou uso incorreto. 

 Implemente a política de classificação de dados trabalhando de forma reversa a partir do uso contextual dos dados e criando um esquema de categorização que leve em conta a importância de determinado conjunto de dados para as operações de uma organização. 

 **Etapas da implementação** 
+  Realize um inventário dos vários tipos de dados que existem para sua workload. 
  +  Para obter mais detalhes sobre categorias de classificação de dados, consulte o [whitepaper Data Classification](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) (Classificação de dados). 
+  Determine a importância, a confidencialidade, a integridade e a disponibilidade dos dados com base no risco para a organização. Use esses requisitos para agrupar dados em um dos níveis de classificação de dados adotados. 
  +  Por exemplo, consulte [Four simple steps to classify your data and secure your startup](https://aws.amazon.com/blogs/startups/four-simple-steps-to-classify-your-data-and-secure-your-startup/) (Quatro etapas simples para classificar seus dados e proteger sua startup). 
+  Audite periodicamente seu ambiente em busca de dados que não estejam etiquetados ou classificados e classifique-os e etiquete-os apropriadamente. 
  +  Por exemplo, consulte [Data Catalog e crawlers no AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html). 
+  Estabeleça um catálogo de dados que forneça recursos de auditoria e governança. 
+  Determine e documente procedimentos de manipulação para cada classe de dados. 
+  Use automação para auditar periodicamente seu ambiente em busca de dados que não estejam etiquetados ou classificados e classifique-os e etiquete-os apropriadamente. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Leveraging Nuvem AWS to Support Data Classification](https://docs.aws.amazon.com/whitepapers/latest/data-classification/leveraging-aws-cloud-to-support-data-classification.html) (Utilizar a Nuvem AWS para oferecer compatibilidade com a classificação de dados) 
+  [Políticas de tag do AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) 

 **Vídeos relacionados:** 
+ [ Enabling agility with data governance on AWS](https://www.youtube.com/watch?v=vznDgJkoH7k) (Ativar a agilidade com governança de dados na AWS)

# SUS04-BP02 Usar tecnologias compatíveis com seus padrões de acesso e de armazenamento de dados
<a name="sus_sus_data_a3"></a>

 Use tecnologias de armazenamento mais adequadas à maneira como seus dados são acessados e armazenados a fim de reduzir os recursos provisionados e, ao mesmo tempo, comportar sua workload. 

 **Antipadrões comuns:** 
+  Você pressupõe que todas as workloads têm padrões de acesso e armazenamento de dados semelhantes. 
+  Você usa apenas um nível de armazenamento, supondo que todas as workloads se encaixem nesse nível. 
+  Você pressupõe que os padrões de acesso aos dados permanecerão consistentes ao longo do tempo. 

 **Benefícios de estabelecer esta prática recomendada:** selecionar e otimizar suas tecnologias de armazenamento com base em padrões de armazenamento e acesso aos dados ajudará a reduzir os recursos de nuvem necessários a fim de atender às suas necessidades empresariais e melhorar a eficiência geral da workload de nuvem. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Selecione a solução de armazenamento mais alinhada a seus padrões de acesso ou considere a possibilidade de alterar seus padrões de acesso para alinhamento com a solução de armazenamento a fim de maximizar a eficiência da performance. 
+  Avalie suas características de dados e padrão de acesso a fim de reunir as principais características de suas necessidades de armazenamento. Principais características a serem consideradas: 
  +  **Tipo de dados:** estruturados, semiestruturados e não estruturados 
  +  **Crescimento dos dados:** delimitado, não vinculado 
  +  **Durabilidade de dados:** persistente, efêmero, transitório 
  +  **Padrões de acesso:** leituras ou gravações, frequência, picos ou consistentes 
+  Migre os dados para a tecnologia de armazenamento apropriada que seja compatível com suas características de dados e padrão de acesso. Veja alguns exemplos de tecnologias de armazenamento da AWS e suas principais características:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_data_a3.html)
+  Para sistemas de armazenamento que têm tamanho fixo, como Amazon EBS ou Amazon FSx, monitore o espaço de armazenamento disponível e automatize a alocação de armazenamento ao atingir um limite. Você pode utilizar o Amazon CloudWatch para coletar e analisar diferentes métricas para o [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html) e o [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring-cloudwatch.html). 
+  As classes de armazenamento do Amazon S3 podem ser configuradas em nível de objeto e um único bucket pode conter objetos armazenados em todas as classes de armazenamento. 
+  Você também pode usar políticas de ciclo de vida do Amazon S3 para realizar a transição automática de objetos entre classes de armazenamento ou remover dados sem nenhuma alteração na aplicação. Em geral, você precisa fazer uma compensação entre a eficiência dos recursos, a latência de acesso e a confiabilidade ao considerar esses mecanismos de armazenamento. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Tipos de volume do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) 
+  [Armazenamento de instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) 
+  [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html) 
+ [ Características de E/S do Amazon EBS ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html)
+ [ Uso de classes de armazenamento do Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)
+  [O que é o Amazon Glacier?](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html) 

 **Vídeos relacionados:** 
+  [Architectural Patterns for Data Lakes on AWS (Padrões arquitetônicos para data lakes na AWS)](https://www.youtube.com/watch?v=XpTly4XHmqc&ab_channel=AWSEvents) 
+ [ Deep dive on Amazon EBS (STG303-R1) ](https://www.youtube.com/watch?v=wsMWANWNoqQ)
+ [ Optimize your storage performance with Amazon S3 (STG343) ](https://www.youtube.com/watch?v=54AhwfME6wI)
+ [ Building modern data architectures on AWS (Criação de arquiteturas de dados na AWS) ](https://www.youtube.com/watch?v=Uk2CqEt5f0o)

 **Exemplos relacionados:** 
+ [ Driver CSI do Amazon EFS ](https://github.com/kubernetes-sigs/aws-efs-csi-driver)
+ [ Driver CSI do Amazon EBS ](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
+ [ Utilitários do Amazon EFS ](https://github.com/aws/efs-utils)
+ [ Escalabilidade automática do Amazon EBS ](https://github.com/awslabs/amazon-ebs-autoscale)
+ [ Exemplos do Amazon S3 ](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html)

# SUS04-BP03 Usar políticas para gerenciar o ciclo de vida de seus conjuntos de dados
<a name="sus_sus_data_a4"></a>

Gerencie o ciclo de vida de todos os seus dados e aplique a exclusão automaticamente para minimizar o armazenamento total necessário para sua workload.

 **Antipadrões comuns:** 
+  Você exclui dados manualmente. 
+  Você não exclui nenhum de seus dados de workload. 
+  Você não move os dados para níveis de armazenamento mais eficientes em termos de energia com base em seus requisitos de retenção e acesso. 

 **Benefícios de estabelecer esta prática recomendada:** O uso de políticas de ciclo de vida de dados garante acesso e retenção de dados eficientes em uma workload. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Os conjuntos de dados geralmente têm diferentes requisitos de retenção e acesso durante seu ciclo de vida. Por exemplo, seu aplicativo pode precisar de acesso frequente a alguns conjuntos de dados por um período limitado. Depois disso, esses conjuntos de dados são acessados com pouca frequência. 

 Para gerenciar com eficiência seus conjuntos de dados ao longo de seu ciclo de vida, configure políticas de ciclo de vida, que são regras que definem como lidar com conjuntos de dados. 

 Com as regras de configuração do ciclo de vida, é possível orientar o serviço de armazenamento específico a fazer a transição de um conjunto de dados para níveis de armazenamento mais eficientes em termos de energia, arquivá-lo ou excluí-lo. 

 **Etapas da implementação** 
+  [Classifique conjuntos de dados em sua workload.](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_data_a2.html) 
+  Defina procedimentos de manipulação para cada classe de dados. 
+  Defina políticas automatizadas de ciclo de vida para aplicar regras de ciclo de vida. Aqui estão alguns exemplos de como configurar políticas de ciclo de vida automatizadas para diferentes serviços de armazenamento do AWS:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_data_a4.html)
+  Exclua volumes não utilizados, snapshots e dados que estão fora do período de retenção. Aproveite os recursos do serviço nativo, como o tempo de vida útil do Amazon DynamoDB ou retenção de log do Amazon CloudWatch para exclusão. 
+  Agregue e compacte dados quando possível com base nas regras do ciclo de vida. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Otimize suas regras de ciclo de vida do Amazon S3 com a análise de classe de armazenamento do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html) 
+  [Avaliar recursos com o Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 

 **Vídeos relacionados:** 
+  [Simplifique o ciclo de vida de seus dados e otimize os custos de armazenamento com o ciclo de vida do Amazon S3](https://www.youtube.com/watch?v=53eHNSpaMJI) 
+ [ Reduza seus custos de armazenamento usando Lente de Armazenamento do Amazon S3](https://www.youtube.com/watch?v=A8qOBLM6ITY)

# SUS04-BP04 Usar elasticidade e automação para expandir o armazenamento em bloco ou o sistema de arquivos
<a name="sus_sus_data_a5"></a>

Use a elasticidade e automação para expandir o armazenamento em bloco ou o sistema de arquivos à medida que os dados aumentarem e minimizar o total de armazenamento provisionado.

 **Antipadrões comuns:** 
+  Você adquire um grande armazenamento em bloco ou sistema de arquivos para necessidades futuras. 
+  Você provisiona em excesso as operações de entrada e saída por segundo (IOPS) de seu sistema de arquivos. 
+  Você não monitora a utilização de seus volumes de dados. 

 **Benefícios do estabelecimento desta prática recomendada:** minimizar o provisionamento em excesso do sistema de armazenamento reduz os recursos ociosos e melhora a eficiência geral da workload. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Crie armazenamento em bloco ou sistemas de arquivos com alocação de tamanho, throughput e latência apropriados à workload. Use a elasticidade e automação para expandir o armazenamento em bloco ou o sistema de arquivos à medida que os dados aumentarem sem precisar provisionar em excesso esses serviços de armazenamento. 

 **Etapas da implementação** 
+  Para armazenamento fixo como o [Amazon EBS](https://aws.amazon.com/ebs/), verifique se está monitorando a quantidade de armazenamento usada em comparação com o tamanho geral do armazenamento e, se possível, crie automação para aumentar o tamanho do armazenamento ao atingir um limite. 
+  Use volumes elásticos e serviços gerenciados de dados em bloco para automatizar a alocação de armazenamento adicional à medida que os seus dados persistentes aumentarem. A título de exemplo, você pode usar os [Volumes Elásticos do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html) para alterar o tamanho ou o tipo de volume ou ajustar a performance dos volumes do Amazon EBS. 
+  Escolha a classe de armazenamento, modo de performance e modo de throughput corretos para seu sistema de arquivos para atender à necessidade de seus negócios, sem a ultrapassar. 
  + [ Desempenho do Amazon EFS ](https://docs.aws.amazon.com/efs/latest/ug/performance.html)
  + [ Performance do volume do Amazon EBS em instâncias Linux ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html)
+  Defina os níveis pretendidos de utilização para seus volumes de dados e redimensione os volumes fora dos intervalos esperados. 
+  Dimensione adequadamente volumes somente leitura para acomodar os dados. 
+  Migre os dados para depósitos de objetos a fim de evitar o provisionamento de capacidade em excesso que ocorre com os tamanhos de volumes fixos no armazenamento em bloco. 
+  Analise regularmente volumes elásticos e sistemas de arquivos para encerrar volumes ociosos, reduzir recursos com excesso de provisionamento e se ajustar ao tamanho de dados atual. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Documentação do Amazon FSx](https://docs.aws.amazon.com/fsx/index.html) 
+  [O que é o Amazon Elastic File System?](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) 

 **Vídeos relacionados:** 
+ [ Aprofundamento em Volumes Elásticos do Amazon EBS ](https://www.youtube.com/watch?v=Vi_1Or7QuOg)
+ [ Amazon EBS e estratégias de otimização de snapshots para melhorar a performance e reduzir os custos ](https://www.youtube.com/watch?v=h1hzRCsJefs)
+ [ Otimização de custo e performance do Amazon EFS usando práticas recomendadas ](https://www.youtube.com/watch?v=9kfeh6_uZY8)

# SUS04-BP05 Remover dados desnecessários ou redundantes
<a name="sus_sus_data_a6"></a>

Remova dados desnecessários ou redundantes para minimizar os recursos de armazenamento necessários para armazenar seus conjuntos de dados. 

 **Antipadrões comuns:** 
+  Você duplica dados que podem ser facilmente obtidos ou recriados. 
+  Você faz backup de todos os dados sem considerar sua criticidade. 
+  Você apenas exclui dados irregularmente, em eventos operacionais ou não os exclui. 
+  Você armazena dados de forma redundante, independentemente da durabilidade do serviço de armazenamento. 
+  Você ativa o versionamento do Amazon S3 sem qualquer justificativa comercial. 

 **Benefícios do estabelecimento desta prática recomendada:** A remoção de dados desnecessários reduz o tamanho de armazenamento necessário para sua workload e o impacto ambiental da workload. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Não armazene dados de que você não precisa. Automatize a exclusão de dados desnecessários. Use tecnologias que eliminem dados duplicados em níveis de arquivo e bloco. Aproveite a replicação de dados nativos e os recursos de redundância dos serviços. 

 **Etapas da implementação** 
+  Avalie se você pode evitar o armazenamento de dados usando conjuntos de dados disponíveis publicamente no [AWS Data Exchange](https://aws.amazon.com/data-exchange/) e [Dados abertos no AWS](https://registry.opendata.aws/). 
+  Use mecanismos que possam duplicar dados no nível de bloco e objeto. Aqui estão alguns exemplos de como desduplicar dados no AWS:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_data_a6.html)
+  Analise o acesso aos dados para identificar dados desnecessários. Automatize as políticas de ciclo de vida. Aproveite os recursos do serviço nativo, como o [tempo de vida útil do Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html), [ciclo de vida do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) ou [retenção de log do Amazon CloudWatch](https://docs.aws.amazon.com/managedservices/latest/userguide/log-customize-retention.html) para exclusão. 
+  Use os recursos de virtualização de dados no AWS para manter os dados em sua origem e evitar a duplicação de dados. 
  +  [Virtualização de dados nativos da nuvem no AWS](https://www.youtube.com/watch?v=BM6sMreBzoA) 
  +  [Laboratório: Otimizar padrão de dados usando o compartilhamento de dados do Amazon Redshift](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/) 
+  Use a tecnologia de backup que pode fazer backups incrementais. 
+  Aproveite a durabilidade do [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html) e a [replicação do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) para atender às suas metas de durabilidade em vez de tecnologias autogerenciadas (como uma Redundant Array of Independent Disks [RAID – Matriz redundante de discos independentes]). 
+  Centralize o log e rastreie os dados, elimine a duplicação de entradas de log idênticas e estabeleça mecanismos para ajustar a prolixidade quando necessário. 
+  Preencha os caches com antecedência somente quando justificável. 
+  Estabeleça o monitoramento e a automação de cache para redimensioná-lo de forma adequada. 
+  Remova implantações e ativos desatualizados de depósitos de objetos e caches de borda ao enviar novas versões da sua workload. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Retenção de dados do log de alterações no CloudWatch Logs](https://docs.aws.amazon.com/Amazon/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) 
+  [Eliminação de duplicação de dados no Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-data-dedup.html) 
+  [Recursos do Amazon FSx for ONTAP incluindo a eliminação da duplicação de dados](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html#features-overview) 
+  [Invalidar arquivos no Amazon CloudFront](https://docs.aws.amazon.com/Amazon/latest/DeveloperGuide/Invalidation.html) 
+  [Usar o AWS Backup para fazer backup e restaurar sistemas de arquivos do Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) 
+  [O que é o Amazon CloudWatch Logs?](https://docs.aws.amazon.com/Amazon/latest/logs/WhatIsLogs.html) 
+  [Trabalhar com backups no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 

 **Vídeos relacionados:** 
+  [Correspondência difusa e desduplicação de dados com ML Transforms para o AWS Lake Formation](https://www.youtube.com/watch?v=g34xUaJ4WI4) 

 **Exemplos relacionados:** 
+  [Como analiso meus logs de acesso ao servidor do Amazon S3 usando o Amazon Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) 

# SUS04-BP06 Usar sistemas de arquivos compartilhados ou armazenamento para acessar dados comuns
<a name="sus_sus_data_a7"></a>

Adote armazenamento ou sistemas de arquivos compartilhados para evitar a duplicação de dados e viabilize fuma infraestrutura mais eficiente para sua workload. 

 **Antipadrões comuns:** 
+  Você provisiona armazenamento para cada cliente específico. 
+  Você não desanexa o volume de dados dos clientes inativos. 
+  Você não fornece acesso a armazenamento em plataformas e sistemas. 

 **Benefícios do estabelecimento desta prática recomendada:** o uso de armazenamento ou sistemas de arquivos permite que os dados sejam compartilhados com um ou mais consumidores sem precisar copiá-los. Isso ajuda a reduzir os recursos de armazenamento necessários à workload. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Se você tiver vários usuários ou aplicações que acessam os mesmos conjuntos de dados, o uso da tecnologia de armazenamento compartilhado é essencial para viabilizar uma infraestrutura eficiente para sua workload. A tecnologia de armazenamento compartilhado oferece um local central para armazenar e gerenciar conjuntos de dados e evitar a duplicação de dados. Ela também impõe a consistência dos dados em sistemas diferentes. Além disso, a tecnologia de armazenamento compartilhado permite o uso mais eficiente da potência computacional, visto que vários recursos podem acessar e processar os dados ao mesmo tempo em paralelo. 

 Busque dados dos serviços de armazenamento compartilhado somente quando necessário e desanexe os volumes não usados para liberar recursos. 

 **Etapas da implementação** 
+  Migre dados para o armazenamento compartilhado quando eles tiverem vários consumidores. Veja aqui alguns exemplos de tecnologia de armazenamento compartilhado na AWS:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_data_a7.html)
+ Copie os dados para ou busque os dados de sistemas de arquivos compartilhados somente quando necessário. A título de exemplo, você pode usar um [sistema de arquivos do Amazon FSx for Lustre respaldado pelo Amazon S3](https://aws.amazon.com/blogs/storage/new-enhancements-for-moving-data-between-amazon-fsx-for-lustre-and-amazon-s3/) e carregar somente o subconjunto de dados necessário para processar os trabalhos para o Amazon FSx.
+ Exclua dados conforme apropriado para os seus padrões de uso, tal como descrito em [SUS04-BP03 Usar políticas para gerenciar o ciclo de vida de seus conjuntos de dados](sus_sus_data_a4.md).
+  Desvincule volumes de clientes que não estão utilizando-os ativamente. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Vincular seu sistema de arquivos a um bucket do Amazon S3 ](https://docs.aws.amazon.com/fsx/latest/LustreGuide/create-dra-linked-data-repo.html)
+ [ Como usar o Amazon EFS para AWS Lambda em suas aplicações sem servidor ](https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aws-lambda-in-your-serverless-applications/)
+ [ Amazon EFS Intelligent-Tiering Intelligent-Tiering otimiza os custos para workloads com padrões de acesso variáveis](https://aws.amazon.com/blogs/aws/new-amazon-efs-intelligent-tiering-optimizes-costs-for-workloads-with-changing-access-patterns/)
+ [ Como usar o Amazon FSx com seu repositório de dados on-premises](https://docs.aws.amazon.com/fsx/latest/LustreGuide/fsx-on-premises.html)

 **Vídeos relacionados:** 
+ [ Otimização de custos de armazenamento com o Amazon EFS ](https://www.youtube.com/watch?v=0nYAwPsYvBo)

# SUS04-BP07 Minimizar a movimentação de dados entre redes
<a name="sus_sus_data_a8"></a>

Use o armazenamento de objetos ou os sistemas de arquivos compartilhados para acessar dados comuns e minimizar os recursos totais de rede exigidos para comportar a movimentação de dados da workload.

 **Antipadrões comuns:** 
+  Você armazena todos os dados na mesma Região da AWS independentemente de onde os usuários dos dados estão. 
+  Você não otimiza o tamanho e o formato dos dados antes de movimentá-los na rede. 

 **Benefícios de estabelecer esta prática recomendada:** otimizar a movimentação de dados na rede reduz os recursos totais de rede necessários à workload e reduz o respectivo impacto ambiental. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A movimentação de dados em sua organização exige recursos de computação, rede e armazenamento. Use técnicas para minimizar a movimentação de dados e melhorar a eficiência geral da workload. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Considere a proximidade dos dados ou dos usuários como um fator de decisão ao [selecionar uma região para sua workload](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/). 
+  Particione serviços consumidos regionalmente para que os dados específicos da região sejam armazenados na região em que eles são consumidos. 
+  Use formatos de arquivo eficientes (como Parquet ou ORC) e compacte os dados antes movimentá-los na rede. 
+  Não movimente dados não usados. Alguns exemplos que podem ajudar você a evitar a movimentação de dados não utilizados: 
  +  Reduza as respostas de API apenas aos dados relevantes. 
  +  Agregue os dados onde não houver necessidade de informações detalhadas (em nível de registro). 
  +  Consulte [Laboratório do Well-Architected: Otimizar padrão de dados usando o compartilhamento de dados do Amazon Redshift.](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/). 
  +  Considere [o compartilhamento de dados entre contas no AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html). 
+  Use serviços que podem ajudar você a executar código mais perto dos usuários da workload.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_data_a8.html)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Otimizar a sua infraestrutura da AWS para sustentabilidade, Parte III: Redes](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/) 
+  [Infraestrutura global da AWS](https://aws.amazon.com/about-aws/global-infrastructure/) 
+  [Principais recursos do Amazon CloudFront incluindo a rede global de borda do CloudFront](https://aws.amazon.com/cloudfront/features/) 
+  [Compactação de solicitações HTTP no Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gzip.html) 
+  [Intermediar a compactação de dados com o Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-output-compression.html#HadoopIntermediateDataCompression) 
+  [Carregar arquivos de dados compactados do Amazon S3 no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html) 
+  [Distribuição de arquivos compactados com o Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html) 

 **Vídeos relacionados:** 
+ [ Demystifying data transfer on AWS (Desmistificação da transferência de dados na AWS) ](https://www.youtube.com/watch?v=-MqXgzw1IGA)

 **Exemplos relacionados:** 
+ [ Arquitetura para a sustentabilidade: reduza a movimentação de dados entre redes ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)

# SUS04-BP08 Fazer backup de dados somente quando for difícil recriar
<a name="sus_sus_data_a9"></a>

Evite fazer backup de dados que não têm valor empresarial para minimizar os requisitos de recurso de armazenamento da workload. 

 **Antipadrões comuns:** 
+  Você não tem uma estratégia de backup para seus dados. 
+  Você faz backup de dados que podem ser recriados com facilidade. 

 **Benefícios do estabelecimento desta prática recomendada:** evitar backups de dados não essenciais reduz os recursos de armazenamento necessários à workload e diminui o respectivo impacto ambiental. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Evitar o backup de dados desnecessários pode ajudar a reduzir os custos e os recursos de armazenamento usados pela workload. Faça backup somente de dados com valor empresarial ou que sejam necessários para atender aos requisitos de conformidade. Examine as políticas de backup e exclua armazenamentos temporários que não forneçam valor em um cenário de recuperação. 

 **Etapas da implementação** 
+  Implemente uma política de classificação de dados como descrito em [SUS04-BP01 Implementar uma política de classificação de dados](sus_sus_data_a2.md). 
+  Use a criticidade da estratégia de classificação de dados e backup de design com base no [objetivo de tempo de recuperação (RTO) e no objetivo de ponto de recuperação (RPO](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)). Evite fazer backup de dados não essenciais. 
  +  Exclua os dados que podem ser recriados com facilidade. 
  +  Exclua dados temporários dos seus backups. 
  +  Exclua cópias locais de dados, a menos que o tempo necessário para restaurar esses dados de um local comum exceda seus Acordos de Serviço (SLAs). 
+  Use uma solução automatizada ou um serviço gerenciado para fazer backup de dados essenciais aos negócios. 
  +  O [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) é um serviço totalmente gerenciado que facilita a centralização e a automatização da proteção de dados nos serviços da AWS, na nuvem e no ambiente on-premises. Para obter orientações práticas sobre como criar backups automatizados usando o AWS Backup, consulte [Laboratórios do Well-Architected: Teste de backup e restauração de dados](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/). 
  +  [Automatize backups e otimize os custos de backup do Amazon EFS usando o AWS Backup](https://aws.amazon.com/blogs/storage/automating-backups-and-optimizing-backup-costs-for-amazon-efs-using-aws-backup/). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_identified_backups_data.html)
+ [REL09-BP03 Realizar o backup de dados automaticamente](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_automated_backups_data.html)
+ [REL13-BP02 Usar estratégias de recuperação definidas para atender aos objetivos de recuperação](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)

 **Documentos relacionados:** 
+  [Usar o AWS Backup para fazer backup e restaurar sistemas de arquivos do Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) 
+  [Snapshots do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html) 
+  [Trabalhar com backups no Amazon Relational Database Service](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 
+ [Parceiro do APN: parceiros que podem ajudar com o backup](https://partners.amazonaws.com/search/partners?keyword=Backup)
+ [AWS Marketplace: produtos que podem ser usados para backup ](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [ Como fazer backup do Amazon EFS ](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [ Como fazer backup do Amazon FSx para Windows File Server ](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [ Backup e restauração do Amazon ElastiCache (Redis OSS) ](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)

 **Vídeos relacionados:** 
+ [AWS re:Invent 2021: Backup, recuperação de desastres e proteção contra ransomware com a AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup Demonstração do AWS Backup: Backup entre contas e entre regiões ](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341) ](https://www.youtube.com/watch?v=av8DpL0uFjc)

 **Exemplos relacionados:** 
+ [ Laboratório do Well-Architected: Teste de backup e restauração de dados ](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [ Laboratório do Well-Architected: Backup e restauração com failback para workload do Analytics ](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [ Laboratório do Well-Architected: Recuperação de desastres: backup e restauração ](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)

# Hardware e serviços
<a name="a-sus-hardware-and-services"></a>

**Topics**
+ [SUS 5 Como selecionar e usar hardware e serviços em nuvem na arquitetura para apoiar os objetivos de sustentabilidade?](sus-05.md)

# SUS 5 Como selecionar e usar hardware e serviços em nuvem na arquitetura para apoiar os objetivos de sustentabilidade?
<a name="sus-05"></a>

Procure oportunidades para reduzir os impactos na sustentabilidade da workload fazendo mudanças nas suas práticas de gerenciamento de hardware. Minimize a quantidade de hardware necessária para provisionar e implantar e escolha o hardware e os serviços mais eficientes para sua workload específica. 

**Topics**
+ [SUS05-BP01 Usar a quantidade mínima de hardware para atender às suas necessidades](sus_sus_hardware_a2.md)
+ [SUS05-BP02 Usar tipos de instância com o mínimo de impacto](sus_sus_hardware_a3.md)
+ [SUS05-BP03 Usar serviços gerenciados](sus_sus_hardware_a4.md)
+ [SUS05-BP04 Otimizar o uso de aceleradores de computação baseados em hardware](sus_sus_hardware_a5.md)

# SUS05-BP01 Usar a quantidade mínima de hardware para atender às suas necessidades
<a name="sus_sus_hardware_a2"></a>

Use a quantidade mínima de hardware para sua workload para atender com eficiência às suas necessidades de negócios.

 **Antipadrões comuns:** 
+  Você não monitora a utilização de recursos. 
+  Você tem recursos com baixo nível de utilização em sua arquitetura. 
+  Você não analisa a utilização de hardware estático para determinar se é necessário redimensioná-lo. 
+  Você não define metas de utilização de hardware para sua estrutura de computação com base nos KPIs de negócios. 

 **Benefícios do estabelecimento desta prática recomendada:** dimensionar corretamente os recursos de nuvem ajuda a reduzir o impacto ambiental da workload, a economizar e a manter os parâmetros de performance. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Selecione do modo mais eficiente o número total de hardware necessário à workload para melhorar a eficiência geral. A Nuvem AWS oferece flexibilidade para expandir ou reduzir dinamicamente a quantidade de recursos por meio de diversos mecanismos, como o [AWS Auto Scaling](https://aws.amazon.com/autoscaling/), para atender a mudanças na demanda. Ela também fornece [APIs e SDKs](https://aws.amazon.com/developer/tools/) que permitem que os recursos sejam modificados com o mínimo de esforço. Use esses recursos para fazer alterações frequentes nas implementações da workload. Além disso, use as orientações sobre dimensionamento correto das ferramentas da AWS para operar com eficiência o recursos de nuvem e atender às suas necessidades empresariais. 

 **Etapas da implementação** 
+  Escolha os tipos de instância mais adequados às suas necessidades. 
  + [ Como faço para escolher o tipo de instância do Amazon EC2 apropriado para minha workload? ](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
  + [ Seleção de tipo de instância baseada em atributos para frota do Amazon EC2. ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
  + [ Criar um grupo do Auto Scaling usando seleção de tipo de instância baseada em atributos. ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)
+  Escale usando pequenos incrementos para workloads variáveis. 
+  Use várias opções de compra de computação para equilibrar flexibilidade, escalabilidade e economia no uso de instâncias. 
  +  As [instâncias sob demanda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html) são mais adequadas para workloads novas, com estado e com picos que não podem ter flexibilidade com relação ao tipo de instância, local e tempo. 
  +  As [instâncias spot ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) são excelentes para complementar as outras opções para aplicações tolerantes a falhas e flexíveis. 
  +  Utilize [Savings Plans para computação](https://aws.amazon.com/savingsplans/compute-pricing/) para workloads de estado estável que permitem flexibilidade se suas necessidades (como AZ, região, famílias de instâncias ou tipos de instância) mudarem. 
+  Use uma variedade de instâncias e zonas de disponibilidade para maximizar a disponibilidade da aplicação e aproveitar o excesso de capacidade quando possível. 
+  Use as recomendações de dimensionamento correto das ferramentas da AWS para fazer ajustes na workload. 
  + [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
  + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+  Negocie Acordos de Serviço (SLAs) que permitam uma redução temporária na capacidade enquanto a automação implanta recursos de substituição. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Otimizar a sua infraestrutura da AWS para sustentabilidade, Parte I: Computação ](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)
+ [ Seleção de tipo de instância baseada em atributo do Auto Scaling para Amazon EC2 Fleet ](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [ Documentação do AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/index.html)
+  [Otimização do Lambda: otimização da performance](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/) 
+  [Documentação do Auto Scaling](https://docs.aws.amazon.com/autoscaling/index.html) 

 **Vídeos relacionados:** 
+ [Criar um ambiente de computação eficiente em termos de custo, energia e recursos](https://www.youtube.com/watch?v=8zsC5e1eLCg)

 **Exemplos relacionados:** 
+ [ Laboratórios do Well-Architected: Dimensionamento correto com o AWS Compute Optimizer e utilização de memória habilitada (Nível 200) ](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)

# SUS05-BP02 Usar tipos de instância com o mínimo de impacto
<a name="sus_sus_hardware_a3"></a>

Monitore continuamente e use novos tipos de instância para aproveitar as melhorias de eficiência de energia.

 **Antipadrões comuns:** 
+  Você usa apenas uma família de instâncias. 
+  Você usa apenas instâncias x86. 
+  Você especifica um tipo de instância em sua configuração do Amazon EC2 Auto Scaling. 
+  Você usa instâncias da AWS de um modo para o qual elas não foram projetadas (por exemplo, você usa instâncias otimizadas para computação em uma workload com uso intenso de memória). 
+  Você não avalia os novos tipos de instância regularmente. 
+  Você não verifica as recomendações de ferramentas de dimensionamento correta da AWS, como o [AWS Compute Optimizer.](https://aws.amazon.com/compute-optimizer/) 

 **Benefícios do estabelecimento desta prática recomendada:** Ao usar instâncias com eficiência de energia e dimensionadas corretamente, você consegue reduzir ainda mais o impacto ambiental e o custo da workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Usar instâncias eficientes na workload de nuvem é essencial para reduzir o uso de recursos e os custos. Monitore continuamente o lançamento de novos tipos de instância e aproveite as melhorias de eficiência de energia, incluindo os tipos de instância projetados para comportar workloads específicas, como treinamento e inferência de machine learning e transcodificação de vídeo. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Conheça e explore os tipos de instância que podem reduzir o impacto ambiental de sua workload. 
  +  Inscreva-se nas [Novidades da AWS](https://aws.amazon.com/new/) para ficar por dentro das tecnologias e instâncias mais recentes da AWS. 
  +  Conheça os diversos tipos de instâncias da AWS. 
  +  Conheça as instâncias baseadas em AWS Graviton, que oferecem a melhor performance por watt de energia usada no Amazon EC2 assistindo aos vídeos [re:Invent 2020 - Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances (re:Invent 2020 - aprofundamento em instâncias do Amazon EC2 alimentadas por processadores AWS Graviton2)](https://www.youtube.com/watch?v=NLysl0QvqXU) e [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances (Aprofundamento em AWS Graviton3 e instâncias C7g do Amazon EC2)](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents). 
+  Planeje e migre sua workload para tipos de instância com impacto mínimo. 
  +  Defina um processo para avaliar novos recursos ou instâncias para sua workload. Aproveite a agilidade da nuvem para testar rapidamente como novos tipos de instância podem melhorar a sustentabilidade ambiental de sua workload. Use métricas de proxy para mensurar quantos recursos são necessários para concluir uma unidade de trabalho. 
  +  Se possível, modifique sua workload para trabalhar com diferentes números de vCPUs e diferentes quantidades de memória para maximizar sua escolha de tipo de instância. 
  +  Considere migrar sua workload para instâncias baseadas em Graviton e melhorar a eficiência da performance da workload. 
    +  [AWS Graviton Fast Start](https://aws.amazon.com/ec2/graviton/fast-start/) 
    +  [Considerações ao migrar workloads para instâncias do Amazon Elastic Compute Cloud baseadas no AWS Graviton](https://github.com/aws/aws-graviton-getting-started/blob/main/transition-guide.md) 
    +  [AWS Graviton2 para ISVs](https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/welcome.html) 
  +  Considere selecionar a opção AWS Graviton em seu uso de [serviços gerenciados da AWS.](https://github.com/aws/aws-graviton-getting-started/blob/main/managed_services.md) 
  +  Migre sua workload para regiões que ofereçam instâncias com o menor impacto na sustentabilidade e atendam aos seus requisitos de negócios. 
  +  Para workloads de machine learning, utilize hardware específico para sua workload, como [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)e aos [Amazon EC2 DL1.](https://aws.amazon.com/ec2/instance-types/dl1/) Instâncias do AWS Inferentia, como instâncias Inf2, oferecem performance até 50% melhor por watt em relação a instâncias comparáveis do Amazon EC2. 
  +  Use o [Amazon SageMaker AI Inference Recommender](https://docs.aws.amazon.com/sagemaker/latest/dg/inference-recommender.html) para dimensionar endpoints de inferência de ML corretamente. 
  +  Para workloads com picos (workloads com requisitos irregulares para capacidade adicional), use [instâncias de performance expansível.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html) 
  +  Para workloads sem estado e tolerantes a falhas, use [Instâncias Spot do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) para aumentar a utilização geral da nuvem e reduzir o impacto na sustentabilidade de recursos não utilizados. 
+  Opere e otimize a instância de sua workload. 
  +  Para workloads efêmeras, avalie [métricas do Amazon CloudWatch para instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics) , como `CPUUtilization` , a fim de identificar se a instância está ociosa ou é subutilizada. 
  +  Para workloads estáveis, verifique as ferramentas da AWS para dimensionamento correto, como o [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) , em intervalos regulares a fim de identificar oportunidades para otimizar e dimensionar instâncias corretamente. 
    + [ Laboratório do Well-Architected: Recomendações de dimensionamento correto ](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
    + [ Laboratório do Well-Architected: Dimensionamento correto com o Compute Optimizer ](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
    + [ Laboratório do Well-Architected: Otimizar padrões de hardware e observar KPIs de sustentabilidade ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Otimizar a sua infraestrutura da AWS para sustentabilidade, Parte I: Computação](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/) 
+  [AWS Graviton](https://aws.amazon.com/ec2/graviton/) 
+  [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/) 
+  [Frotas de reserva de capacidade do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cr-fleets.html) 
+  [Frota spot do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html) 
+  [Funções: configuração de função do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) 
+ [ Seleção de tipo de instância baseada em atributos para frota do Amazon EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [Criar aplicações sustentáveis, eficientes e com custo otimizado na AWS](https://aws.amazon.com/blogs/compute/building-sustainable-efficient-and-cost-optimized-applications-on-aws/)
+ [ Como o Painel de Sustentabilidade da Contino ajuda os clientes a otimizar sua pegada de carbono ](https://aws.amazon.com/blogs/apn/how-the-contino-sustainability-dashboard-helps-customers-optimize-their-carbon-footprint/)

 **Vídeos relacionados:** 
+  [Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances (Aprofundamento em instâncias do Amazon EC2 alimentadas por processadores AWS Graviton2)](https://www.youtube.com/watch?v=NLysl0QvqXU) 
+  [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances (Aprofundamento em AWS Graviton3 e instâncias C7g do Amazon EC2)](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents) 
+ [ Criar um ambiente de computação eficiente em termos de custo, energia e recursos ](https://www.youtube.com/watch?v=8zsC5e1eLCg)

 **Exemplos relacionados:** 
+ [ Solução: orientações sobre como otimizar workloads de aprendizado profundo para sustentabilidade na AWS](https://aws.amazon.com/solutions/guidance/optimizing-deep-learning-workloads-for-sustainability-on-aws/)
+  [Laboratório do Well-Architected: Recomendações de dimensionamento correto](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/) 
+  [Laboratório do Well-Architected: Dimensionamento correto com o Compute Optimizer](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/) 
+  [Laboratório do Well-Architected: Otimizar padrões de hardware e observar KPIs de sustentabilidade](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/) 
+ [ Laboratório do Well-Architected: Migração de serviços para o Graviton ](https://www.wellarchitectedlabs.com/sustainability/100_labs/100_migrate_services_to_graviton/)

# SUS05-BP03 Usar serviços gerenciados
<a name="sus_sus_hardware_a4"></a>

Use serviços gerenciados para operar com maior eficiência na nuvem.

 **Antipadrões comuns:** 
+  Você usa instâncias do Amazon EC2 com baixa utilização para executar suas aplicações. 
+  Sua equipe interna gerencia apenas a workload e não tem tempo para se concentrar em inovação ou simplificações. 
+  Você implanta e mantém tecnologias para tarefas que podem ser executadas com maior eficiência em serviços gerenciados. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Com o uso de serviços gerenciados, a responsabilidade é transferida para a AWS, que tem insights referentes a milhões de clientes que podem ajudar a promover inovações inéditas e melhorar a eficiência. 
+  O serviço gerenciado distribui o impacto ambiental do serviço entre vários usuários por causa do ambiente de gerenciamento de vários locatários. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Como os serviços gerenciados, a responsabilidade por manter a alta utilização e otimizar a sustentabilidade do hardware implantado é transferida para a AWS. Os serviços gerenciados também eliminam as despesas operacionais e administrativas da manutenção de um serviço, o que permite que sua equipe tenha mais tempo para se concentrar na inovação. 

 Avalie sua workload para identificar componentes que podem ser substituídos por serviços gerenciados da AWS. Por exemplo, o [Amazon RDS](https://aws.amazon.com/rds/), o [Amazon Redshift](https://aws.amazon.com/redshift/) e o [Amazon ElastiCache](https://aws.amazon.com/elasticache/) fornecem um serviço gerenciado de banco de dados. O [Amazon Athena](https://aws.amazon.com/athena/), o [Amazon EMR](https://aws.amazon.com/emr/) e o [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) fornecem um serviço gerenciado de análise. 

 **Etapas da implementação** 

1.  Faça um inventário de serviços e componentes para sua workload. 

1.  Avalie e identifique componentes que podem ser substituídos por serviços gerenciados. Veja aqui alguns exemplos de quando você pode pensar em usar um serviço gerenciado:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_hardware_a4.html)

1.  Identifique dependências e crie um plano de migração. Atualize runbooks e manuais and playbooks de forma apropriada. 
   +  O [AWS Application Discovery Service](https://aws.amazon.com/application-discovery/) coleta e apresenta automaticamente informações detalhadas sobre dependências e utilização de aplicações para ajudar você a tomar decisões bem fundamentadas ao planejar a migração. 

1.  Teste o serviço antes de migrar para o serviço gerenciado. 

1.  Use o plano de migração para substituir serviços auto-hospedados por serviço gerenciado. 

1.  Monitore continuamente o serviço após a conclusão da migração para fazer ajustes conforme necessário e otimizar o serviço. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Produtos da Nuvem AWS](https://aws.amazon.com/products/)
+ [Calculadora de custo total de propriedade (TCO) da AWS](https://calculator.aws/#/)
+  [Amazon DocumentDB](https://aws.amazon.com/documentdb/) 
+  [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) 
+  [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://aws.amazon.com/msk/) 

 **Vídeos relacionados:** 
+ [ Operações em nuvem em escala com o AWS Managed Services](https://www.youtube.com/watch?v=OCK8GCImWZw)

# SUS05-BP04 Otimizar o uso de aceleradores de computação baseados em hardware
<a name="sus_sus_hardware_a5"></a>

Otimize o uso de instâncias com computação acelerada para reduzir as demandas de infraestrutura física de sua workload.

 **Antipadrões comuns:** 
+  Você não está monitorando o uso da GPU. 
+  Você está usando uma instância de finalidade geral para workload, enquanto uma instância criada especificamente pode oferecer maior desempenho, menor custo e melhor desempenho por watt. 
+  Você está usando aceleradores de computação baseados em hardware para tarefas em que são mais eficientes usando alternativas baseadas em CPU. 

 **Benefícios de estabelecer esta prática recomendada:** Ao otimizar o uso de aceleradores baseados em hardware, você pode reduzir as demandas de infraestrutura física de sua workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Se você precisar de alta capacidade de processamento, poderá se beneficiar do uso de instâncias com computação acelerada, que fornecem acesso a aceleradores de computação baseados em hardware, como unidades de processamento gráfico (GPUs) e matrizes de portas programáveis em campo (FPGAs). Esses aceleradores de hardware executam certas funções, como processamento gráfico ou correspondência de padrões de dados, com mais eficiência do que alternativas baseadas em CPU. Muitas workloads aceleradas, como renderização, transcodificação e machine learning, são altamente variáveis em termos de uso de recursos. Execute este hardware somente pelo tempo necessário e desative-as com automação quando não precisar mais delas para reduzir o consumo de recursos. 

## Etapas da implementação
<a name="implementation-steps"></a>
+  Identifique quais [instâncias com computação acelerada](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html) podem atender aos seus requisitos. 
+  Para workloads de machine learning, utilize hardware específico para sua workload, como [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)e o [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/). Instâncias do AWS Inferentia, como instâncias Inf2, oferecem [performance até 50% melhor por watt em relação a instâncias comparáveis do Amazon EC2](https://aws.amazon.com/machine-learning/inferentia/). 
+  Colete métricas de uso para suas instâncias com computação acelerada. Por exemplo, você pode usar o agente do CloudWatch para coletar métricas como `utilization_gpu` e `utilization_memory` para suas GPUs, conforme mostrado em [Colete métricas da GPU NVIDIA com o Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html). 
+  Otimize o código, a operação de rede e as configurações dos aceleradores de hardware para garantir que o hardware subjacente seja totalmente utilizado. 
  +  [Otimizar as configurações da GPU](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/optimize_gpu.html) 
  +  [Monitoramento e otimização de GPU no Deep Learning AMI](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-gpu.html) 
  +  [Otimização de E/S para ajuste de desempenho de GPU de treinamento de aprendizado profundo no Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/optimizing-i-o-for-gpu-performance-tuning-of-deep-learning-training-in-amazon-sagemaker/) 
+  Use as mais recentes bibliotecas de alto desempenho e drivers de GPU. 
+  Use automação para liberar instâncias de GPU quando não estiverem em uso. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Computação acelerada](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing) 
+ [ Vamos, arquiteto\$1 Arquitetura com chips e aceleradores personalizados ](https://aws.amazon.com/blogs/architecture/lets-architect-custom-chips-and-accelerators/)
+ [ Como faço para escolher o tipo de instância do Amazon EC2 apropriado para minha workload? ](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+  [Instâncias VT1 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/vt1/) 
+ [ Escolha o melhor acelerador de IA e compilação de modelo para inferência de visão computacional com o Amazon SageMaker AI ](https://aws.amazon.com/blogs/machine-learning/choose-the-best-ai-accelerator-and-model-compilation-for-computer-vision-inference-with-amazon-sagemaker/)

 **Vídeos relacionados:** 
+ [ How to select Amazon EC2 GPU instances for deep learning (Como selecionar instâncias de GPU do Amazon EC2 para aprendizado profundo) ](https://www.youtube.com/watch?v=4bVrIbgGWEA)
+  [Deploying Cost-Effective Deep Learning Inference (Implantação de inferência de aprendizado profundo econômico)](https://www.youtube.com/watch?v=WiCougIDRsw) 

# Processo e cultura
<a name="a-sus-process-and-culture"></a>

**Topics**
+ [SUS 6 Como os processos organizacionais apoiam as metas de sustentabilidade?](sus-06.md)

# SUS 6 Como os processos organizacionais apoiam as metas de sustentabilidade?
<a name="sus-06"></a>

Procure oportunidades para reduzir seu impacto na sustentabilidade fazendo mudanças nas suas práticas de desenvolvimento, teste e implantação. 

**Topics**
+ [SUS06-BP01 Adotar métodos que podem apresentar melhorias na sustentabilidade rapidamente](sus_sus_dev_a2.md)
+ [SUS06-BP02 Manter a workload atualizada](sus_sus_dev_a3.md)
+ [SUS06-BP03 Aumentar a utilização de ambientes de desenvolvimento](sus_sus_dev_a4.md)
+ [SUS06-BP04 Usar parques de dispositivos gerenciados para testes](sus_sus_dev_a5.md)

# SUS06-BP01 Adotar métodos que podem apresentar melhorias na sustentabilidade rapidamente
<a name="sus_sus_dev_a2"></a>

Adote métodos e processos para validar possíveis aprimoramentos, minimizar o custo dos testes e fornecer pequenas melhorias.

 **Antipadrões comuns:** 
+  A avaliação da sustentabilidade de sua aplicação é uma tarefa que é feita apenas uma vez no início de um projeto. 
+  Como o processo de lançamento para introduzir pequenas alterações em prol da eficiência dos recursos é muito trabalhoso, sua workload ficou ultrapassada. 
+  Você não tem mecanismos para melhorar a sustentabilidade de sua workload. 

 **Benefícios do estabelecimento desta prática recomendada:** por meio da criação de um processo para introduzir e monitorar melhorias de sustentabilidade, você conseguirá adotar novos recursos e capacidades, eliminar problemas e melhorar a eficiência da workload continuamente. 

 **Nível de risco exposto se esta prática recomendada não é estabelecida:** médio 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Teste e valide as possíveis melhorias de sustentabilidade antes de implantá-las na produção. Considere o custo do teste ao calcular o benefício futuro potencial de uma melhoria. Desenvolva métodos de teste de baixo custo para oferecer pequenas melhorias. 

 **Etapas da implementação** 
+  Adicione requisitos de melhoria da sustentabilidade às suas pendência de desenvolvimento. 
+  Use um [processo de melhoria](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/improvement-process.html) iterativo para identificar, avaliar, priorizar, testar e implantar essas melhorias. 
+  Melhore e otimize continuamente seus processos de desenvolvimento. A título de exemplo, [automatize seu processo de entrega de software usando pipelines de integração contínua e entrega contínua](https://aws.amazon.com/getting-started/hands-on/set-up-ci-cd-pipeline/) a fim de testar e implantar possíveis melhorias para reduzir o nível de esforço e limitar os erros provocados por processos manuais. 
+  Desenvolva e teste possíveis melhorias usando os componentes representativos mínimos viáveis para reduzir o custo dos testes. 
+  Avalie continuamente o impacto das melhorias e faça ajustes conforme necessário. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [A AWS viabiliza soluções de sustentabilidade](https://aws.amazon.com/sustainability/) 
+ [ Práticas de desenvolvimento ágil escaláveis com base no AWS CodeCommit](https://aws.amazon.com/blogs/devops/scalable-agile-development-practices-based-on-aws-codecommit/)

 **Vídeos relacionados:** 
+ [ Entregar arquiteturas sustentáveis e de alta performance ](https://www.youtube.com/watch?v=FBc9hXQfat0)

 **Exemplos relacionados:** 
+  [Laboratório do Well-Architected: Transformação de relatório de custo e uso em relatório de eficiência](https://www.wellarchitectedlabs.com/sustainability/300_labs/300_cur_reports_as_efficiency_reports/) 

# SUS06-BP02 Manter a workload atualizada
<a name="sus_sus_dev_a3"></a>

Mantenha sua workload atualizada para adotar recursos eficientes, eliminar problemas e melhorar a eficiência geral da workload. 

 **Antipadrões comuns:** 
+ Você pressupõe que sua arquitetura atual é estática e não será atualizada ao longo do tempo.
+  Você não tem nenhum sistema ou ritmo regular para avaliar se software ou pacotes atualizados são compatíveis com sua workload. 

 **Benefícios do estabelecimento desta prática recomendada:** ao estabelecer um processo para manter a workload atualizada, você pode adotar novos recursos e capacidades, resolver problemas e aumentar a eficiência da workload.

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Sistemas operacionais, tempos de execução, middleware, bibliotecas e aplicações atualizados podem melhorar a eficiência da workload e facilitar a adoção de tecnologias mais eficientes. Um software atualizado também pode incluir recursos para medir o impacto na sustentabilidade da workload com maior precisão, pois os fornecedores oferecem recursos para atender às suas próprias metas de sustentabilidade. Adote um ritmo regular para manter a workload atualizada com os recursos e versões mais recentes. 

 **Etapas da implementação** 
+  Defina um processo e um cronograma para avaliar novos recursos ou instâncias para sua workload. Aproveite a agilidade da nuvem para testar rapidamente como novos recursos podem melhorar sua workload com o intuito de: 
  +  Reduzir impactos de sustentabilidade. 
  +  Obter eficiências de performance. 
  +  Remover barreiras de melhorias planejadas. 
  +  Aumentar sua capacidade de medir e gerenciar impactos na sustentabilidade. 
+  Fazer o inventário de software e arquitetura da workload e identificar os componentes que precisam ser atualizados. 
  +  Você pode usar o [AWS Systems Manager Inventory](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html) para coletar metadados de sistema operacional (SO), aplicação e instância das instâncias do Amazon EC2 e entender rapidamente quais instâncias executam o software e as configurações exigidas pela política de software e quais instâncias precisam ser atualizadas. 
+  Entenda como atualizar os componentes de sua workload.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/sus_sus_dev_a3.html)
+  Use automação no processo de atualização para reduzir o nível de esforço para implantar novos recursos e limitar erros causados por processos manuais. 
  +  Você pode usar [CI/CD](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/) para atualizar automaticamente AMIs, imagens de contêiner e outros artefatos relacionados à sua aplicação de nuvem. 
  +  Você pode usar ferramentas como o [Gerenciador de Patches do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) para automatizar o processo de atualizações de sistema e programar a atividade usando as [Janelas de Manutenção do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html). 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Central de arquitetura da AWS](https://aws.amazon.com/architecture) 
+  [Quais as novidades da AWS](https://aws.amazon.com/new/?ref=wellarchitected&ref=wellarchitected) 
+  [Ferramentas do desenvolvedor na AWS](https://aws.amazon.com/products/developer-tools/) 

 **Exemplos relacionados:** 
+  [Laboratórios do Well-Architected: Gerenciamento de inventário e patches](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/) 
+  [Laboratório: AWS Systems Manager](https://mng.workshop.aws/ssm.html) 

# SUS06-BP03 Aumentar a utilização de ambientes de desenvolvimento
<a name="sus_sus_dev_a4"></a>

Aumente a utilização dos recursos para desenvolver, testar e compilar suas workloads.

 **Antipadrões comuns:** 
+  Você provisiona ou encerra manualmente seus ambientes de compilação. 
+  Você mantém seus ambientes de compilação em execução independentemente de atividades de teste, compilação ou lançamento (por exemplo, execução de um ambiente fora do horário de expediente dos membros de sua equipe de desenvolvimento). 
+  Você provisiona recursos em excesso para seus ambientes de compilação. 

 **Benefícios do estabelecimento desta prática recomendada:** ao aumentar a utilização dos ambientes de compilação, você pode melhorar a eficiência geral de sua workload de nuvem e, ao mesmo tempo, alocar recursos aos compiladores para que eles desenvolvam, testem e compilem com eficiência. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

 Use a automação e a infraestrutura como código para ativar ambientes de compilação quando necessário e desativá-los quando não forem usados. Um padrão comum é programar períodos de disponibilidade que coincidam com as horas de trabalho dos membros da equipe de desenvolvimento. A configuração dos ambientes de teste deve ser bem semelhante à do ambiente de produção. Entretanto, procure oportunidades para usar tipos de instância com capacidade de expansão, instâncias spot do Amazon EC2, serviços de banco de dados com escalabilidade automática, contêineres e tecnologias sem servidor para alinhar a capacidade de desenvolvimento e teste com o uso. Limite o volume de dados apenas para atender os requisitos de teste. Se usar dados de produção no teste, explore possibilidades para compartilhar os dados da produção em vez de movimentá-los. 

 **Etapas da implementação** 
+  Use a infraestrutura como código para provisionar os ambientes de compilação. 
+  Use a automação para gerenciar o ciclo de vida de seus ambientes de desenvolvimento e teste e maximizar a eficiência dos recursos de compilação. 
+  Use estratégias para maximizar a utilização de seus ambientes de desenvolvimento e teste. 
  +  Use ambientes representativos mínimos viáveis para desenvolver e testar possíveis melhorias. 
  +  Utilize tecnologias sem servidor, se possível. 
  +  Use instâncias sob demanda para complementar os dispositivos de desenvolvedor. 
  +  Use tipos de instância com capacidade de expansão, instâncias spot e outras tecnologias para alinhar a capacidade de compilação com o uso. 
  +  Adote serviços de nuvem nativos para acesso seguro ao shell de instância em vez de implantar frotas de hosts bastion. 
  +  Escale automaticamente seus recursos de compilação de acordo com seus trabalhos de compilação. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Gerenciador de sessões do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 
+  [Instâncias de performance expansível do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html) 
+  [O que é o AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
+ [O que é o AWS CodeBuild? ](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [ Programador de Instâncias da AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)

 **Vídeos relacionados:** 
+ [ Práticas recomendadas de integração contínua ](https://www.youtube.com/watch?v=77HvSGyBVdU)

# SUS06-BP04 Usar parques de dispositivos gerenciados para testes
<a name="sus_sus_dev_a5"></a>

Use parques de dispositivos gerenciados para testar com eficiência um novo recurso em um conjunto representativo de hardware.

 **Antipadrões comuns:** 
+  Você testa e implanta manualmente sua aplicação em dispositivos físicos individuais. 
+  Você não usa o serviço de testes de aplicação para testar e interagir com suas aplicações (por exemplo, Android, iOS e aplicações Web) em dispositivos físicos reais. 

 **Benefícios do estabelecimento desta prática recomendada:** usar parques de dispositivos gerenciados para testar aplicações habilitadas para a nuvem oferece inúmeros benefícios: 
+  Eles contam com recursos mais eficientes para testar a aplicação em uma ampla variedade de dispositivos. 
+  Eles eliminam a necessidade de infraestrutura interna para testes. 
+  Eles oferecem diversos tipos de dispositivo, incluindo hardware mais antigo e menos conhecido, eliminando a necessidade de atualizações de dispositivo desnecessárias. 

 **Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>

Usar parques de dispositivos gerenciados pode ajudar a otimizar o processo de testes de novos recursos em um conjunto representativo de hardware. Os parques de dispositivos gerenciados oferecem diversos tipos de dispositivo, incluindo hardware mais antigo e menos conhecido, e evita o impacto sobre a sustentabilidade por parte do cliente devido a atualizações desnecessárias de dispositivo.

 **Etapas da implementação** 
+  Defina seus requisitos e plano de testes (como tipo de teste, sistemas operacionais e programação dos testes). 
  +  Você pode usar o [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) para coletar e analisar dados do lado do cliente e moldar seu plano de testes. 
+  Selecione o parque de dispositivos gerenciados capaz de atender aos seus requisitos de teste. Por exemplo, você pode usar o [AWS Device Farm](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) para testar e conhecer o impacto de suas alterações sobre um conjunto representativo de hardware. 
+  Use a integração contínua/implantação contínua (CI/CD) para programar e executar seus testes. 
  + [ Integração do AWS Device Farm com seu pipeline de CI/CD para executar testes Selenium entre navegadores ](https://aws.amazon.com/blogs/devops/integrating-aws-device-farm-with-ci-cd-pipeline-to-run-cross-browser-selenium-tests/)
  + [ Compilação e teste de aplicativos iOS e iPadOS com DevOps e serviços móveis da AWS](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)
+  Avalie continuamente os resultados dos testes e faça as melhorias necessárias. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [Lista de dispositivos do AWS Device Farm](https://awsdevicefarm.info/)
+ [ Visualização do painel do CloudWatch RUM ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-view-data.html)

 **Exemplos relacionados:** 
+ [ Aplicativo de exemplo do AWS Device Farm para Android ](https://github.com/aws-samples/aws-device-farm-sample-app-for-android)
+ [ Aplicativo de exemplo do AWS Device Farm para iOS ](https://github.com/aws-samples/aws-device-farm-sample-app-for-ios)
+ [ estes Web Appium para AWS Device Farm](https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium-python)

 **Vídeos relacionados:** 
+ [Otimização de aplicações por meio de insights sobre o usuário final com o Amazon CloudWatch RUM ](https://www.youtube.com/watch?v=NMaeujY9A9Y)