AWS Well Architected Framework - Anotações

README.md

AWS Well Architected Framework

O que é?

• Melhores práticas pra utilização da AWS
• Princípios, melhores práticas e questões
• Pensado pelos SA em contato com os clientes
• Como você está usando os serviços da AWS?
• Se o alicerce não está sólido, o prédio inteiro pode ser comprometido

Objetivos

• Avaliar e medir as arquiteturas, buscando melhorias
• Identificar áreas para melhorias
• Gerar backlog / reduzir dívida técnica
• Mecanismo de Gating
• Due Dilligence

Pilares

Excelência operacional

• Key Points:
  • Definir prioridades baseadas nas necessidades do negócio
  • Design para operações
  • Avaliar preparação operacional (workload e time)
  • Entender saúde operacional e usar feedback para melhoria
  • Preparar e responder a eventos
    • Playbooks e runbooks, responsabilidade
  • Aprender da experiência, compartilhar conhecimento com organização
• Rodar e monitorar os sistemas, objetivo é entregar valor de negócio e melhorar os processos continuamente
• Ambientes tradicionais VS desejado
  • Mudanças manuais | Mudanças via código e automação
  • Procedimentos e docs desatualizada | Documentação através de código
  • Medo de mudanças, agrupamento em grandes releases | Mudanças incrementais
  • Game days e testes de carga são raros | Game days, infra reproduzível
  • Reativo, de um incidente a outro | Antecipar falhar e aprender com falhas operacionais e ajustar o código
• Serviço chave = CloudFormation para IaC
• Dividido em 3 áreas

Preparar (Prepare)

• Design da arquitetura para as operações
  • Decisões que permitem deployment contínuo e menor risco
• Medir a "pronteza" operacional do workload e do time
  • Padronização e compartilhamento de runbooks
  • Checklists
  • Scripts, reduzir erros humanos
• Definir prioridades operacionais
  • Objetivos de negócio
  • Focar onde terão mais impacto
• AWS Config para deixar tudo compliant
• Exemplo = Entender necessidade de negócio
  • Prioridades operacionais devem considerar as necessidades do negócio
  • Compliance e auditoria
  • Benefícios e riscos
  • Speed to market VS Reliability
  • Performance VS Cost optimization

Operar (Operate)

• Entender a saúde operacional com métricas
• Responder a eventos (planejados ou não)
  • Promoções
  • Aumentos em uso e falhas
• Runbooks e playbooks para consistência na resposta a eventos
• CloudWatch para medir saúde operacional e reagir a eventos
• Best practice: Processo para gerenciar incidentes e eventos
  • Eventos observados
  • Eventos que precisam de intervenção
    • Incidentes
    • Recorrentes ou não podem ser resolvidos (problemas)
  • Resposta bem definida
  • Time responsável pela resposta / escalação
  • Processo de escalação bem definido
  • Escalação p/ suporte
  • Notificação para usuários sobre impacto
  • Status dashboard

Evoluir (Evolve)

• Aprender com a experiência
• Compartilhar com a organização
• ElasticSearch para pegar insights a partir dos logs
• Contínuous incremental improvements
• Feedback loops e experiência
• Fazer mudanças, medir e considerar
• Compartilhar o que aprendeu
• Best practice: Feedback loops
  • Identificar áreas de melhoria
  • Priorização e gerar melhorias
  • Feedback nos procedimentos de operação devem ser usados para melhorá-los
  • Operations activities
  • Customer experience
  • Business & dev teams
  • Reconhecer o sucesso ou falha de uma melhoria

Segurança

• Proteger informação e sistemas
• Ambiente tradicional
  • "Egg shell model", apenas refina as arestas, proteção superficial
  • Logging e auditing esporádicos, alguns dispositivos nem tem logs, cada um de uma forma
  • Pode até ter playbook, mas quando eventos acontecem, alguém tem que iniciar e até mesmo reconhecer um incidente de segurança
  • Pessoas ou terceiros para segurança do datacenter
  • Muitos processos manuais
• Cloud
  • Security in all layers, IAM e mudanças
  • Responder a eventos como código
  • Quem pode fazer o que
  • Preparar para eventos de segurança e automação
  • Automático, controlado por versão e escalável
  • Proteção dos dados (transit e rest)
  • Deixar as pessoas longe dos dados
• Key service = IAM
• Best practices
  • IAM, apenas usuários autenticados
  • RBAC
  • Permissões granulares
  • Senhas fortes, MFA
  • Federação com Directory Service

Identity and Access Management

• Serviços = IAM, Organizations, MFA, Temporary Token
• Gerenciar chaves e credenciais efetivamente
• Não usar a conta root
• Access keys nunca serem colocadas em código ou armazenadas de forma insegura
• Cognito = Identity Broke
  • Identificador único (Joãozinho)
  • Conectar com Identity Providers (Google+, Amazon e FAcebook)
  • Implementar melhores práticas é fácil
  • Acesso temporário limitado

Detective Controls

• Serviços = CloudTrail, Config, CloudWatch
• Detectar ou identificar eventos de segurança
• Frameworks de governança, processos de qualidade, auditoria, resposta a ameaças
• Inventário dos assets
• Lifecycle controls
• Internal auditing para examinar os controls
• Alertas automáticos
• Best practice = Autmatizar respostas de seguranças
  • Playbook = depende de alguém executar/reconhecer o evento
  • Detective controls p/ automatizar
  • CloudTrail + CloudWatch Events
  • Modificar uma EC2 ou S3 via qualquer mecanismo (console ou API)
  • Evento é acionado que executa o control
  • Ex: Quando alguém adicionar uma regra no SG, aciona uma Lambda que manda uma notificação e remove a regra
    • CloudTrail + Lambda + SNS

Infrastructure Protection

• Serviços = VPC, Inspector, Shield, WAF
• Metodologias para melhores práticas e obrigações da indústria ou regulamentais
• Edge protection
• Monitorar ingress e egress
• Logging
• Monitoring
• Network & boundary protection
  • Security group = firewall
  • Portas absolutamente necessárias
  • Separar em camadas (subnets) para isolação lógicas
  • Bastion / jump boxes
  • Host based controls (iptables, anti-malware)
• Service-specific access controls
  • S3
  • ACLs
  • IAM user policies
  • Access Policies => Principal elements ou NotPrincipal

Data Protection

• Serviços = Macie, KMS, S3, EBS, ELB, RDS (encryption in transit / at rest)
• Usar controles e padrões pra manter os dados confidenciais e preservar sua integridade e disponibilidade
• CID - Três pilares de segurança da informação
  • Confidencialidade = Só quem precisa tem acesso
    • Policies, IAM, RBAC, criptografia
  • Integridade = Não corromper, comprometer ou danificar os arquivos
    • Pode ser um sinônimo pra confiabilidade
    • Versionamento, MFA delete, checksum, logging
  • Disponibilidade = Dados estão acessíveis sempre que for necessário
    • Pode ser um sinônimo pra durabilidade
    • Redundância, resiliência, multi-az
• Logging detalhado (acessos e mudanças)
• Exemplo best-practice: Criptografia em trânsito e at rest
  • ACM, criptografia
  • End-to-end encryption
• Criptografia de dados
  • Dados
  • Método para criptografia
  • Chaves de criptografia

Incident Response

• Serviços = IAM, CloudFormation (ambiente p/ investigação)
• Processos para responder e mitigar impacto de eventos de segurança
• Equipe de resposta ter uma forma fácil e segura de obter acesso
• CloudFormation = clean room p/ investigação c/ snapshot do EBS
• Game days

Confiabilidade

• Recuperar de falhas e manter demanda
• Ambiente tradicional
  • Testar se coisas funcionam, se consegue manter a demanda normal
  • Testar processos de recuperação = durante a falha
  • Recuperação manual de falhas, anotar procedimento p/ corrigir
  • Múltiplos single-points of failure
  • Adivinhar capacidade
• Ambiente cloud
  • Testar procedimentos de recuperação
  • Automaticamente se recuperar de falhas
  • Escala horizontal
  • Recursos absorver carga
  • Adicionar e escalar recursos automaticamente
• Key service = CloudWatch

Foundations

• Serviços = IAM, VPC, Trusted Advisor (Guia p/ provisionar recursos), Shield (DDoS protection)
• Requisitos de fundação que influenciam a confiabilidade
  • Banda de rede
  • Fora do escopo de 1 único projeto
  • Long lead times
  • Devem ser incorporados durante o planejamento inicial
• Entender limites físicos e constraints de recursos
  • Service limits
  • Rate limits (SLA)
  • Fixed limits (design ocnstraints)
• Alertas e reporting
  • Saber quando está perto de bater um limite
  • AWS gerencia os SLAs
• Exemplo: High availabilty sem single point of failure
  • Sistema continuar rodando com manutençao
  • Multi AZ
  • Load balancing
  • Auto scaling e healing
  • Resiliência do software a condições transientes
  • Conexões redundantes

Change management

• CloudTrail (audits de seg), Config (inventário de recursos e configuração), CloudWatch, AutoScaling
• Agir proativamente
• Monitorar comportamento
• Processo automatizado, controlar quem faz mudanças e como elas são feitas
• SNS
• Monitorar e revisar, respostas automatizadas
• Restarts de recursos não saudáveis
• Best practice = auto scaling

Failure management

• CloudFormation, S3 (backups), Glacier (archive), KMS
• Como saber das falhas, responder e previnir
• Automatizar reações
  • Métrica cruzou threshold
• Analisar recursos que falharam
• Backup dos dados regulares
• Testes de recuperação automatizados
• Best practice = backup e DR
  • Testes periódicos
  • IaC
  • Erros lógicos e físicos
  • Acionar após mudanças significativas
  • RTO e RPO
• Pilot light, etc

Performance Efficiency

• Usar recursos de forma eficiente
• Selecionar os tipos corretos
• Revisar seleção c/ invoações da AWS
• Saber como seus recursos estão performando
• Tradeoffs arquiteturais
• Eficiência X Eficácia
  • Eficiência = Fez as coisas da forma certa, menos recursos
  • Eficácia = Fazer as coisas certas, não enxugar gelo
• Ambiente tradicional
  • Usar mesma tecnologia para tudo
    • Só tem um martelo = tudo vira prego
    • Base relacional ser usada pra tudo
  • Apenas local -- global é muito caro e difícil
  • Muitos servidores que faziam uma coisa, pessoas para gerenciar
  • Difícil de fazer experimentos
• Ambiente cloud
  • Testar novas tecnologias
  • Deploy global
  • Usar arquiteturas serverless
  • Experimentações
  • Approach tecnológico que se encaixa melhor
• Key service = CloudWatch (monitorar, visibilidade p/ performance)

Selection

• Key services = Auto Scaling, EBS, S3, Autoscaling, RDS, Dynamo, VPC (endpoints), Route53 (latency), Direct Connect,
• Variar baseado no design da aplicação, padrões de uso, configurações
• Benchmark / load test
• Monitorar performance
• Best practice = Escolher tamanho apropriado dos recursos
  • Usar arquitetura de referência / quick start deployments
  • Benchmarking, load testing
  • Cost/budget
  • Monitoramento e notificação

Review

• AWS Blog, What's New
• Arquiteturas que evolvem com novos serviços
• Best practice = load testing
  • CloudFormation, provisionar ambientes diferentes para testar
  • Fork do template, mudar, subir ambiente, testar e destruir

Monitoring

• CloudWatch, Lambda (trigger actions)
• Alarmes, contornar problemas de performance com ações para os serviços
• CloudWatch, Kinesis, SQS, Lambda
• Best practice = Performance alarms

Trade-offs

• ElastiCache, CloudFront, Snowball (melhorar performance), RDS (read replicas)
• Espaço (memória ou armazenamento) é usado pra reduzir tempo de processamento e vice-versa
• Recursos geográficos
• Baixa latência, maior vazão
• Direct Connect
• Testar para ver o que fica melhor
• Não violar outros requisitos funcionais
• Monitorar performance
• Best practice = Proximidade e caching
  • Reduzir latência (CDN)
  • Caching
  • Read replicas (mais fácil de implementar)

Otimização de custos

• Evitar custos desnecessários
• Recursos custo-efetivos (RI e Spot)
• Bater supply e demand
• Expenditure awareness
• Otimizar com o tempo
• Ambiente tradicional
  • Custos centralizados (sem revisão)
  • Individuos manter servidores
  • Pay upfront
  • Recursos caros, muito custo para o negócio
  • Custo de manter data centers
• Ambiente cloud
  • Pague pelo que usa, diminui ou aumentar, sem previsão
  • Economias de escala
  • AWS mantém o datacenter
  • Avaliar os sistemas de custo
  • Atribuir custos de IT para áreas
  • Redução de manutenção com serviços
• Serviço chave = Cost allocation tags

Cost-effective resources

• Serviços: RI, Spot, Cost Explorer, Managed Services
• Processo de relatório pode levar 5 horas pra rodar em um servidor pequeno, mas 1 hora em um maior e mais caro
• Managed services p/ reduzir custo (ex. SMTP)
• RI
  • No upfront = Contrato para pagar mensal pela utilização, com desconto
    • Successful billing history
  • Partial upfront = parte do custo deve ser pago upfront
    • Horas restantes são bilhetadas com desconto, mesmo se você não usar
  • All upfront = Compromisso de 1 ou 3 anos
  • Standard = maior desconto (até 72%)
  • Convertible = até 54%, pode mudar atributos desde que o valor seja maior ou igual
    • instance families, operating system, tenancy, and payment option
  • Scheduled = Lançar na janela definida, fração de um dia, semana ou mês
  • Divide (1 t2.large => 4 t2.small)
  • Merge (4 t2.small => 1 t2.large)
• Spot
  • spot blocks = request uninterrupted spot blocks (1 to 6 hours)

Matched supply and demand

• Serviço: Autoscaling
• Extra supply para tempo de provisionamento e falha de recursos
• Demanda fixa ou variável
• Métrica
• Buffering / Queueing requests
• Schedule based (dev/test, DR)

Expenditure awareness

• Serviços: CloudWatch, SNS, Cost Explorer (Forecast)
• Tags
• Cost Explore, Budget
• Partner tools
• Best practice = cost allocation tags = custos agregados por tags
• Padrões em quanto você gasta e entender custos

Optimize over time

• Serviços: AWS Blog, Whats new, Trusted Advisor
• Avaliar deciões de arquitetura pra ver se elas ainda não as mais cost-effective
• Decomission of resources or services
• AWS Trusted Advisor, revisar uso

The Well Architected Review

• O sistema que estão construindo é well-architected?
• Processos de review
• Consistência
• Portifólio de tecnologia da empresa
• Approach consistente para revisar os workloads + conselhos
• Responder questões sobre os pilares
• Não é um audit, e sim uma forma de melhorar as arquiteturas
• Conselho pragmático, que viram que funciona
• Fazer continuamente
• Quanto mais cedo melhor
• Benefícios
  • Build e deploy mais rápido
  • Diminuir ou mitigar riscos
  • Fazer decisões informadas, saber como elas irão impactar
  • Aprender melhores práticas da AWS
• Review está no whitepaper
• Well Architected tool, AWS SA ou APN partners
• Envolver stakeholders
• Free review dos APNs
• Recebe resultados do review, incluindo Statement of Work (SOW) para melhorias
• Se o SOW for aprovado, a AWS vai fornecer $5k em créditos

Well Architected Tool

• Ferramenta para Well Architected Review
• Framework -> Medir -> Melhorar
• Responder perguntas que batem com a forma que a empresa lida com cada pilar
• Review baseada em workloads = Coleção de recursos e código que entrega valor de negócio
  • Alguns recursos em uma ou mais contas
• Rastrear progresso no workload com milestones (Design review, pre go-live, v1.0, new feature)
• Features
  • Definir workloads e fazer reviews
    • QA sobre cada pilar
    • Encontrar recursos úteis
  • Criar um plano de melhoria
    • Em cada questão, com nível de risco e dicas de como reduzir
    • Recomenda membros do APN e Marketplace para corrigir
    • Ordenar pilares de acordo com a sua prioridade
  • Salvar milestones
    • Snapshot do estado do review
    • Status atual de um review de workload
    • Medir progresso
    • Salvar milestone depois que mudanças grandes forem feitas
    • Fazer um workload review
  • Gerar relatórios em PDF
    • Gerar PDF com as respostas, riscos, etc
    • Compartilhar com quem não tem acesso à Well Architected Tool
  • Usar um dashboard
    • Workload reviews feitos, quantos riscos altos, quantos riscos médios
  • Determinar prioridades para pilares