Skip to content

Instantly share code, notes, and snippets.

@GusAntoniassi

GusAntoniassi/00-README.md

Last active August 25, 2023 19:28
Show Gist options
  • Save GusAntoniassi/fe5e9049235dd30f440b1b921e0e2b54 to your computer and use it in GitHub Desktop.
Save GusAntoniassi/fe5e9049235dd30f440b1b921e0e2b54 to your computer and use it in GitHub Desktop.
Download ZIP
[Anotações] Certificação AWS DevOps Professional
Raw
01-udemy.md

Stéphane Maarek - DevOps Professional course

Domain 1: SLDC Automation

(Apenas o que ainda não sabia)

CodeCommit

  • Automation
    • Notifications
      • Settings > Notifications
      • Notification rule
      • Detail type (Full ou Basic)
      • Events que acionam notificações
        • Comentários, PRs, Branches & Tags
      • Target = SNS Topic
    • Triggers
      • Eventos (Push to branch, create branch/tag, delete branch/tag)
      • Service details (SNS ou Lambda)
    • CloudWatch Events
      • Repository State Change
      • Comment on Commit
      • Comment on PR
      • Approval rule template changed
      • CloudTrail API
      • Todos os targets suportados pelo CloudWatch Events
  • Exemplo
    • CodeCommit Trigger p/ Lambda Function

CodeBuild

  • Docker de baixo dos panos
  • Métricas para estatísticas
  • CloudWatch Events para detectar builds falhadas e enviar notificações
  • CloudWatch Alarms para "threshold" de falhas em build
  • CloudWatch Events / Lambda como "cola"
  • SNS Notifications

Buildspec.yml

  • phases = definido pela AWS
    • install = instala o runtime
      • runtime_versions = especifica qual runtime será
        • nodejs: 10
        • pode ter múltiplos
      • commands = comandos adicionais
    • pre_build = setup de config files
      • commands
    • build = o que queremos fazer pra buildar/testar a aplicação
      • commands
    • post_build = cleanup
  • exit status diferente de 0 = phase fail
  • run-as = especificar um usuário linux
    • Dá pra especificar em cada phase também
  • env = variáveis (chave valor), dá pra usar parameter store tbm e git-credential-helper para git privado
  • finally = cleanup, mesmo se der erro
  • artifacts = arquivos que serão mantidos após o build
    • pode ser obtido nas próximas fases do CI/CD
  • cache = ex. dependências para deixar mais rápido
  • Docker & ECR
    • ecr get-login no começo pra falhar rápido

CodeDeploy

appspec.yaml

  • files = arquivos envolvidos no deploy
    • source = arquivo de origem
    • destination = onde o arquivo deve ser copiado
  • hooks = scripts q serão rodados durante o deploy
    • location = caminho do script
    • timeout = tempo pro script rodar
    • runas = usuário pra rodar o script
    • ApplicationStop
    • BeforeInstall
    • AfterInstall
    • ApplicationStart
    • ValidateService

CodePipeline

CloudFormation Action Provider

  • Action mode
    • Create or update stack
    • Delete stack
    • Replace failed stack
    • Create or replace change set
    • Execute change set
  • Stack name, template (do artefato), config file
  • Capabilities
  • Role

Custom Actions c/ Lambda

  • Use cases
    • Aplicar ou atualizar cfn templates
    • Criar recursos on demand em uma stage, e deletar eles em outra (Golden AMI?!) -- load testing
    • Deploy de versões com zero downtime -- EB Swap URL
    • Deploy para ECS
    • Backup de recursos via snapshot de AMI
    • Integração com 3rd party resources, como Slack
  • Precisa ter permissão do IAM para codepipeline:PutJobSuccessResult e codepipeline:PutJobFailureResult

Domain 2: CM and IaC

CloudFormation

  • Dá pra estimar os custos usando o template CloudFormation
  • Diagrama automático para os templates
  • Separação de stacks com camadas
  • Templates hospedados no S3
  • Atualizar um template não dá pra editar, tem que subir um novo no s3
  • Tags da stack serão propagadas para todos os recursos que criar
  • Notificações do template via SNS
  • Termination protection
  • Timeout
  • Rollback on failure opcional
  • Pelo console, possível obter um link para a calculadora mensal com o preço da stack
  • Recursos prefixados
  • CFN não pode ter recursos dinâmicos

Building blocks

  • Resources, obrigatórios
  • Parameters, valores dinâmicos do template
  • Mappings, variáveis estáticas
  • Outputs: referências ao que foi criado
  • Conditionals: Condições
  • Metadata
  • Helpers:
    • References
    • Functions

YAML

  • | = multi line strings

Parameters

  • Reusar templates
  • Alguns templates não dá pra saber de antemão (ex. EC2 key pair)
  • Types podem ajudar a prevenir errors
  • NoEcho = Valor é um secret
  • Pseudo Parameters = Valores que a AWS fornece
    • AWS::AccountId
    • AWS::NotificationARNs
    • AWS::NoValue
    • AWS::Region
    • AWS::StackId
    • AWS::StackName

Mappings

  • Decorar sintaxe
  • !FindInMap [ MapName, TopLevelkey, SecondLevelKey ]

Outputs

  • Opcional
  • Podem ser importados em outras stacks se eles forem exportados
  • Não pode deletar a stack se seus outputs estão sendo referenciados em outro lugar
  • !ImportValue ExportedOutputName

Conditions

  • Comuns: Environment (dev, test, prod), AWS Region, baseado no parâmetro
  • Condição pode referenciar outra condição, parâmetro ou mapping
  • Fn::And, Fn::Equals, Fn::If, Fn::Not, Fn::Or
Conditions:
  CreateProdResources: !Equals [ !Ref EnvType, prod ]
---
Resources:
  MountPoint:
    Type: "AWS::EC2::VolumeAttachment"
    Condition: CreateProdResources

Intrinsic Functions - Must know

  • Fn::Ref: Referência de um recurso
    • Parametro => Retorna o valor
    • Resources => Retorna o ID físico do recurso (ARN, ID, Name)
  • Fn::GetAtt: Atributo de um recurso
    • Documentação
  • Fn::FindInMap: Retorna um valor de um map
  • Fn::ImportValue: Importa os outputs de outro template
  • Fn::Join: Junta valores com um delimitador (string) -- Implode
  • Fn::Sub: Substitui valores com referências ou pseudo-variáveis
    • ${VariableName}
!Sub
  - String
  - { Var1Name: Var1Value, Var2Name: Var2Value }
!Sub String

EC2 User Data

  • Passar o script pela função Fn::Base64
  • Log do user data fica em /var/log/cloud-init-output.log
  • Stack vai ficar verde mesmo se o user data falhar

cfn-init

  • AWS::CloudFormation::Init nos Metadata de um resource
  • Torna configurações complexas legíceis
  • EC2 vai consultar o CloudFormation pra pegar os dados
  • Logs vão para /var/log/cfn-init.log
  • Só ele não vai falhar a stack se a EC2 não subir
  • Chamado no user-data da EC2:
Properties:
  UserData:
    Fn::Base64:
      !Sub |
        #!/bin/bash -xe
        # Get the latest CloudFormation package
        yum update -y aws-cfn-bootstrap
        # Start cfn-init
        /opt/aws/bin/cfn-init -s ${AWS::StackId} -r MyInstance --region ${AWS::Region} || error_exit 'Failed to run cfn-init'
  • EC2 vai ter um bloco Metadata, fora das Properties, com as informações do cfn-init
Metadata:
      Comment: Install a simple Apache HTTP page
      AWS::CloudFormation::Init:
        config:
          packages:
            yum:
              httpd: []
          files:
            "/var/www/html/index.html":
              content: |
                <h1>Hello World from EC2 instance!</h1>
                <p>This was created using cfn-init</p>
              mode: '000644'
          commands:
            hello:
              command: "echo 'hello world'"
          services:
            sysvinit:
              httpd:
                enabled: 'true'
                ensureRunning: 'true'

cfn-signal & wait conditions

  • Rodar o cfn-signal pra sinalizar que a EC2 finalizou a criação
  • Definir WaitCondition no CloudFormation pra dizer pra bloquear o template até receber um sinal
    • Especificar timeouts
  • Adicionar um novo recurso AWS::CloudFormation::WaitCondition, com uma CreationPolicy (também funciona com ASG)
  • /opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackId} --resource SampleWaitCondition --region ${AWS::Region}
  • Timeout definido no formato ISO 8601 - PT (Period + Time) + tempo (H, M, S)
  SampleWaitCondition:
    Type: AWS::CloudFormation::WaitCondition
    CreationPolicy:
      ResourceSignal:
        Timeout: PT2M
        Count: 1

cfn-signal failures

  • Não recebeu o número necessário de signals
  • Verificar se a AMI tem os helper scripts instalados
  • Verificar se o cfn-init e cfn-signal rodaram

CloudFormation Rollbacks

  • Troubleshoot stack creating -> OnFailure=DO_NOTHING
  • Troubleshoot stack update -> error messages

Nested Stacks

  • Reusar templates, considerado melhor prática
  • Pra atualizar a nested stack, tem que atualizar a root stack
  • Requer permissão pra criar IAM e capability
  • Nunca tocar na nested stack sempre fazer pela parent

Change Sets

  • Verificar o que vai ser substituído, atualizado, etc
  • Não vai dizer se a atualização vai dar certo

DeletionPolicy

  • Reter dados ao excluir
  • DeletionPolicy=Retain
    • Preservar/backup quando excluir
    • Funciona pra qualquer recurso ou nested stack
    • DELETE_SKIPPED
  • DeletionPolicy=Snapshot
    • EBS, ElastiCache, RDS, Redshift
    • Faz um snapshot antes de deletar
  • DeletionPolicy=Delete (default)
    • AWS::RDS::DBCluster, default = snapshot
    • S3 = esvaziar o bucket antes de deletar

|---|---| |Retain|Mantém criado| |Snapshot|Gera snapshot, apenas alguns recursos| |Delete|Padrão pra maioria dos recursos, exclui|

Termination Protection

  • Prevenir delete acidental do template cfn

SSM Parameters

  • Type: AWS::SSM::Parameter::Value
  • Default: /EC2/InstanceType
  • Atualização do valor é automática quando atualiza a stack
  • Alguns parâmetros públicos da AWS
    • Latest Amazon Linux: /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2
    • Pegar a lista: aws ssm get-parameters-by-path --path /aws/service/ami-amazon-linux-latest

DependsOn

  • Só cria um recurso depois de criar o outro com sucesso
  • Destroy segue a ordem reversa também

Lambdas in cfn

  • Handler = index.handler
    • index = inline function
    • handler = nome da função que vai ser chamada
  • Properties.Code.ZipFile = <código>
  • 400 caracteres
  • Zipar código fonte e dependências, se tiver
  • S3 versioning => S3ObjectVersion no parâmetro da lambda

Custom Resource

  • Não tem o recurso na AWS
  • On Premise
  • Esvaziar S3 bucket antes de deletar a stack
  • Pegar um AMI ID
  • Invoca uma lambda pra Create, Update e Delete
    • event['RequestType'] = 'Delete'|'Create'|'Update'
  • Service Token = arn da lambda

Drift Detection

  • Não dá pra reverter, apenas ver as mudanças

Status Codes

  • UPDATE_ROLLBACK_FAILED = Mais importante
    • Deletar a stack ou corrigir e continuar rollback
    • Entrar em contato com o suporte AWS

Capabilities

  • InsufficientCapabilitiesException = Passar CAPABILITY_IAM ou CAPABILITY_NAMED_IAM

cfn-hup & cfn-metadata

  • cfn-hup = escutar por mudanças na metadata da EC2
    • Se houver alguma mudança (ex. parâmetro ou template), aplica o update na EC2
    • Atualizar arquivos, instalar outros pacotes, etc
  • /etc/cfn/cfn-hup.conf = parâmetro interval que vai verificar por mudanças, default 15 min
  • /etc/cfn/hooks.d/*.conf
    • Dizer quais serão os triggers, o caminho no Yaml e a ação

Stack Policies

  • Prevenir atualizações na stack
  • Arquivo JSON parecido com uma policy IAM
  • Statement Allow/Deny em uma Action para um Principal/Resource
  • Resource = LogicalResourceId/MeuResource
  • Condition -> StringEquals -> ResourceType = AWS::RDS::DBInstance

Elastic BeanStalk

Plataformas suportadas:

  • .NET on Windows Server

  • Docker

  • GlassFish (Java)

  • Go

  • Java

  • NodeJS

  • PHP

  • Packer

  • Python

  • Ruby

  • Tomcat

  • eb init = cria a aplicação no EB

  • eb create my-env = cria um Environment no EB

  • eb open = abre a aplicação no navegador

  • eb status = mostra se a aplicação está ok

  • eb health = mostra informações detalhadas sobre as instâncias

    • --view cpu = mostra informações de CU das instâncias

  • eb logs = mostra os logs da aplicação sem precisar fazer SSH

  • eb deploy = sobe versão da aplicação

  • eb terminate = destroi o ambiente

  • Versões armazenadas no S3

    • Dá pra baixar um arquivo da versão da aplicação EB

Saved Configurations

  • Backup da configuração como código
    • Útil pra recriar o ambiente em outra região por ex
  • Dá pra pegar pelo CloudFormation template, mas não é "nativo" do EB
  • Saved Configurations = eb cli
    • eb config save dev-env --cfg initial-configuration
    • gera um arquivo na pasta .elasticbeanstalk/saved_configs/initial-configuration.cfg.yml
    • apenas as configurações non-default
  • Setar variável de ambiente = eb setenv FOO=bar
    • Ou setar aws:elasticbeanstalk:application:environment no config file

.ebextensions

  • arquivos pra configurar mais o ambiente EB
  • setar options_settings pra configurar as opções do ambiente
  • dá pra usar namespace como array no yaml ou como um bloco
  • Precedência
    • Configurações aplicadas diretamente (CLI, console, api)
    • Saved Configurations (.elasticbeanstalk/saved_configs)
    • .ebextensions
    • Default values
  • Dá pra adicionar QUALQUER TIPO de recurso do CloudFormation através do .ebextensions
    • Resources, Outputs
    • Passar os nomes via env var com a sintaxe de JSON do CloudFormation (what?!)
    • NOTIFICATION_TOPIC: '{"Ref" : "NotificationTopic"}'
  • Não adicionar production db com ebextensions, pois ela ficará amarrada ao environment
    • Referenciar a tabela externa = env var com o nome/endpoint
  • Commands/Container Commands
    • Passar comandos pras instâncias do EB
    • Commands = antes da aplicação e web server rodar
      • commands: \n foo_command: \n command: touch hello-world.txt \n cwd: /home/ec2-user
    • Container Commands = depois da aplicação e web server rodar, mas antes do deploy da versão
      • Modificar código da aplicação
      • Database migrations
      • leader_only: true = rodar apenas em 1 instancia
      • leader only só pra container commands

Good Features to Know

  • Low cost = free tier = 1 instancia, EIP
  • High availability = prod = 1-4 instancias, LB, ASG
  • Application Version = Limite de 1000
    • Lifecycle = deletar automático
    • Nunca irá deletar a versão deployada
  • Clone environment - console / eb cli
  • Terminate environment = eb terminate
    • deleta todas as instâncias
  • Managed Updates
    • Patches para o ambiente
    • Janela
    • Minor e patch
    • Substituir a instância

EB Deployment Modes

  • All at once = Tudo de uma vez, mais rápido mas tem downtime
  • Rolling = algumas instancias por vez (bucket), depois move pras próximas quando o primeiro bucket está healthy
  • Rolling w/ add. batches = Tipo rolling, mas sobe novas instâncias -- 100% full capacity
  • Immutable: Sobe novas instâncias em um ASG, deploya a versão nas instâncias, troca tudo quando estiver healthy
    • Cria um novo ESG
    • Depois que a instância estiver OK, vincula ela com o ASG de prod
  • Mesmo ELB e ASG
  • Swap URL
    • Criar outro Environemnt e trocar a URL pelo console/cli
    • Vai alterar a configuração do Route53
    • TTL

Worker Environment

  • Tarefas long-running on demand, ou agendadas
  • Cria SQS queue e DLQ
    • Puxa da SQS, tenta processar, empurra pra DLQ se não der certo
  • Ou executa de um cron.yml

Multi-container Docker

  • Mais de um container na mesma instância
  • Cria um cluster ECS por trás
  • Dockerrun.aws.json

AWS Lambda

  • Lambda geralmente é usado como uma "cola" entre os outros serviços nessa prova
  • Runtimes:
    • NodeJS (12.x ou 10.x)
    • Python (3.8 ao 3.6, 2.7)
    • Ruby (2.7 ou 2.5)
    • Java (11, 8)
    • Golang (1.x)
    • .NET (3.1 ou 2.1)
    • Custom runtime (Amazon Linux 1)
  • Timeout máximo da lambda = 15 minutos
  • Long running jobs (mais de 15 minutos) = AWS Batch
  • Funções interagindo entre si = Step Functions
  • Se a função precisar acessar recursos na VPC (RDS privado), precisa estar em uma VPC
  • DLQ = Se a lambda falhar 3x, mandar pro SNS ou SQS
  • X-Ray = APM para lambdas
  • Concurrency = Quantas lambdas rodando ao mesmo tempo
    • Account-wide limit = 1000
    • Dá pra pedir pra aumentar
  • CloudTrail pode logar todas as invocações da lambda

Lambda Triggers

  • API Gateway = Serverless API
    • Por padrão a Lambda só pode ser invocada via SDK, com o API Gateway temos um endpoint HTTP
  • ALB na frente da lambda = front-end HTTP direto
  • CloudWatch Events = "cola" das operações DevOps
    • Reagir a algum evento na nossa infraestrutura e chamar uma lambda pra fazer uma automação
    • Cron schedule
  • CloudWatch Logs = subscription, analisar padrões, alertar
  • CodeCommit = reagir a hooks, função olhar no código e analisar se ngm commitou credenciais
  • DynamoDB Streams = função reagir a mudanças
  • Kinesis = Streams ou Analytics, real-time feed na lambda
  • S3 Events = Sempre que alguem fizer p. ex. PUT de um objeto
    • Assíncrono, Permite DLQ
  • SNS = Reagir a uma mensagem
    • Assíncrono, permite DLQ
  • SQS = Processar mensagens na fila
    • Assíncrono, permite DLQ

Security and env vars

  • Criar uma chave KMS
  • Liberar Write + Decrypt na service role da lambda
  • Enable helpers for encryption in transit -> Vincular com a chave KMS
  • Código personalizado para desencriptar o valor, usa SDK da AWS
  • Usar systems manager ou secrets manager
    • Pegar na função com a AWS SDK

Versions and canary

  • $LATEST = mutável = ultima versão da lambda
  • Publicar versão = imutável = v1
    • Versão = código + configuração
  • Cada versão tem seu ARN
  • Usar versões pra dev, stg, prod
  • Aliases facilitam = ponteiros para versões
  • alias dev = $
  • Blue/Green deployment com weights para os aliases
  • CodeDeploy usa isso por trás dos panos

AWS SAM

  • Transform no cloudformation = indica que aquele template vai ser transformado de alguma forma
  • sam init = cria um boilerplate pra aplicação
  • sam build = cria um template cloudformation e uma pasta com o código + dependências
  • sam invoke = chama a função a partir de um evento
    • precisa do Docker instalado
  • sam package = cria um yaml e faz o upload pra um bucket
  • sam deploy = cria a stack e/ou faz um change set
  • SAM com suporte built-in para CodeDeploy

ECS

  • Cluster = grupamento lógico de instâncias EC2
  • Rodam um cara chamado ECS Agent (que é um container)
  • ECS agent registra a instância no cluster
  • EC2 rodam uma AMI especial, feita pro ECS
  • ecsInstanceRole = role que será atachada às instâncias EC2 do ECS, com algumas liberações pro agent poder chamar o ECS
  • 1 vCPU = 1024 unidades, abstração pra permitir a reserva e compartilhamento entre os containers
  • User data do ECS configura o nome do cluster no /etc/ecs/ecs-config

ECS Task Definition

  • Metadados JSON que vão dizer pro ECS como rodar um ou mais containers
    • Image, port binding (container e host), memória e CPU, env vars, etc
  • Não executa nada, apenas diz como
  • Pergunta do exame: Se uma task/container não consegue puxar imagens do ECR, não consegue falar com o S3, não pode fazer essas coisas, ele está faltando uma task role
    • Task Execution Role = Pull do ECR, enviar logs pro CloudWatch, buscar dados do SSM
    • Task Role = Usada pela task em si, se o container quiser chamar outros serviços da AWS, ele usa isso em vez de ter que mexer nas credenciais
  • Reserva de memória
    • Hard limit (memory) = Valor máximo que aquele container vai poder chegar, se passar disso ele morre
    • Soft limit (memoryReservation) = Valor "recomendado" que aquele container pode usar, ECS vai tentar reservar com base nesse valor se tiver
  • Port Mappings
    • Host port = Porta que será alocada na EC2
    • Container port = Porta que foi exposta no container

ECS Service

  • Define quantas tasks e como elas devem rodar
  • Garantem o número desejado de tasks rodando
  • Atualização das tasks
  • Vincula-se com o load balancer
  • Replica = Roda quantas tasks forem especificadas
  • Daemon = Roda 1 task em cada node
  • Se eu especificar um host port, o service só vai conseguir lançar uma task em cada EC2. Pra poder lançar mais de uma ,tem que usar hostPort = 0 = porta aleatória
  • Dynamic port forwarding = load balancer sabe como "pegar" a porta aleatória, vai rotear pra esses containers
  • Elastic load balancer só pode ser setado quando cria o service
  • AWS obriga a criar um "dummy" target group
  • ELB precisa ter permissão pra conversar com qualquer porta dentro das EC2. Isso pode ser feito liberando o SG do ELB no SG da EC2 para all traffic

ECS IAM Roles

  • ecsInstanceRole = falar com a API do EC2 e ECS, baixar imagens do ECR
  • Task Role = identity provider = ecs-tasks.amazonaws.com

ECR

  • Acesso controlado por IAM (erros de permissão => policy)
  • Rodar login antes de push/pull
  • aws ecr get-login --no-include-email --region us-east-1

Fargate

  • Não precisar gerenciar infraestrutura, é serverless

EB Multi-containers + ECS

  • Cria um cluster ECS + instâncias EC2 + LB + Tasks definitions
  • Dockerrun.aws.json na raíz do fonte
    • Conteúdo é basicamente uma task definition
  • Imagens devem ser pre-built

ECS Auto Scaling

  • Parecido com o autoscaling de EC2
  • Target tracking
    • Rastreia uma métrica ex. CPU
    • Target value = X%
    • Se estiver acima de X%, sobe uma task, se estiver abaixo remove uma task
  • Step scaling
    • Cria um alarme no CW, com base na métrica
    • Adiciona X tasks quando métrica for <= Y
  • Precisa configurar autoscaling para as máquinas

ECS + CloudWatch

  • awslogs log driver = enviar para o log group/region/stream
  • não precisa instalar agent para os logs
  • ecsTaskExecutionRole precisa ter as permissões pra mandar os logs pro CW
  • logs do agent ECS ou do sistema da instância => cw logs agent
  • CloudWatch Container Insights
    • Métricas por container
    • Estilo cadvisor
    • Pagar extra
  • CloudWatch Events
    • State changes
    • Container Instance
    • Task
    • QUando uma task é criada, quando ela terminated
    • Mesmos eventos da aba Events da tela de service
    • Schedule c/ target para ECS Task
      • Batch job c/ Docker

CI/CD Pipeline para ECS

  • CodePipeline => CodeBuild
    • Cria e faz push de uma task do ECR
  • CodePipeline roda um CloudFormation pra criar uma task definition no ECS
  • CodeDeploy no ECS -> Blue/Green Deployments
  • Immutable tag = docker run blablabla/foobar@sha256:asd0213mdsap...

Step Functions

  • Coordenar serviços
  • Use cases = Transcode media files
    • S3 -> Lambda trigger -> Step Functions
      • Lambda -> Rekognition
      • Lambda -> Extrair
      • Desacoplar lambdas
    • Sequenciar AWS Batch jobs, em uma ordem definida
    • API Gateway -> Lambda -> Step Functions -> Admin verification -> SQS, lambda, etc
    • Processo de aprovação de pagamento
  • State Machine = JSON, convertido em um fluxograma
  • Pode rodar por até 1 ano a mesma execução
  • Execution = passar dados e rodar
  • Fazer workflows complexos no fluxo de Devops

API Gateway

  • Não é cobrado muito a fundo, mas pode ter algumas questões sobre como ele funciona
  • Tipo = REST ou WebSocket
  • Swagger / OpenAPI = JSON representando a API
  • Endpoint type
    • Regional = Deploy na região onde você está (ex. Virginia)
    • Edge optimized = Deploy em todos os endpoints do CloudFormation pelo mundo, reduz latência
    • Private = Apenas acessível pela VPC c/ VPC Endpoint
  • Integration type
    • Lambda function = Invoca lambda
    • HTTP = proxy requisição para um endpoint HTTP
    • Mock = Fake
    • AWS Service = Fazer um "front" para algum serviço
    • VPC Link = Ligar com algum endpoint na VPC
  • Request timeout default = 29 segundos
  • API Keys gerenciadas pelo console
  • Enviar logs pro CloudWatch = Tem que criar uma role primeiro
  • Authorizers = Lambda function pra permitir autenticação
  • Private Endpoints = serviços podem acessar o APIGW de forma privada
  • Possível apontar um endpoint Lambda para um alias ou para uma versão
    • Canary Testing com o alias, através da própria integração da Lambda
  • Mapping template = Modificar o conteúdo e corpo que é passado pra uma requisição
    • Velocity Template Language (VTC)
    • Script para editar a requisição = adicionar ou remover um campo de um JSON por exemplo
    • Manter compatibilidade entre versões
    • Possível fazer isso a nível de Integration Request e Integration Response
    • Method Request e Method Response são apenas para entrada e saída do método

Deployment Stages

  • Mudanças no API Gateway = Tem que fazer deployment pra elas irem "live"
  • Deploy é feito em stages (pode usar quantas quiser)
    • dev test prod
    • v1 v2 v3
    • Parâmetros pra configurar a stage
    • Roll back fácil pois o histórico de deployment é mantido
  • Stage variables = Env vars para o stage
    • Valores que mudam frequentemente
    • Não precisa fazer deploy da API de novo
    • ARN da lambda, HTTP endpoint, mapping templates
    • Passado no objeto "context" da lambda

Canary Deployments

  • Qualquer stage, % do tráfego que o canal vai receber
  • Métricas e logs separados (logging)
  • API Gateway > Stage > Canary
  • Override variáveis do stage
  • Na hora de fazer o deploy, aparece o nome do stage + "Canary Enabled"

Throttling

  • Defaults
    • 10.000 r/s (por conta)
    • 5.000 de uma vez (por conta)
    • Throttling a nível de lambda deve ser considerado também
      • Default: 1.000 concorrentes por conta
  • Usage Plans
    • Throttling personalizado
    • Method throttling
    • Associar com uma API Key

Front AWS Services

  • Expor alguns serviços como APIs
  • Configurar a Região, SErviço, Subdomain, Method, Action Type/Name
  • Execution Role precisa ter permissões pra chamar aquele serviço
    • Principal = API GAteway

API Gateway - Velocity Template

Código para integração com mensagens do Slack (recebe um parâmetro json message e manda a requisição pro Slack):

{
    "channel": "#teste-gus-public",
    "username": "API Gateway",
    "text": "$input.path('$.message')",
    "icon_emoji": ":ghost:"
}

AWS OpsWorks

  • OpsWorks Stacks (único que cai na prova)
    • Receitas do Chef para deploy da aplicação
    • Já usando Chef, quer migrar pra AWS
  • OpsWorks for Chef Automate
  • OpsWorks for Puppet Enterprise
  • Custom Cookbooks = Git, S3 ou HTTP
  • Layers = blueprints para um conjunto de EC2. Configurações, pacotes, perfis e SGs
    • OpsWorks (EC2), ECS ou RDS (DB existente, apenas registra no OW)
  • Time-based = Agendado, inicia e para, tem que criar uma nova instância
  • Load-based = Responde a mudanças de CPU, memória ou carga da aplicação
    • Precisa habilitar load based autoscaling pra funcionar
    • Configurações UP e DOWN, para as métricas mencionadas acima
    • OU, baseado em alarmes do CloudWatch
  • Você precisa "criar" as máquinas antes. Até as máquinas load-based, elas ficam stopped e são ligadas quando acionadas
  • Apps = como o código armazenado no repo deve ser levado pras instâncias
  • Trigger deploy manual pelo painel
  • Run command = Update custom cookbooks, executar receitas, setup, configure, upgrade do OS
    • Seleciona as instâncias que irá rodar

Stack Lifecycle Events

Uma das coisas mais importantes sobre o OpsWorks

  • Cada layer tem 5 eventos de lifecycle
  • Quando um evento ocorre em uma instância, o OpsWorks roda as receitas necessárias
  • Setup = Depois que a instância terminou de bootar
  • Configure
    • Um dos mais importantes
    • É acionado em TODAS as instâncias da stack, quando um desses eventos acontece:
      • Instância fica online ou offline
      • Associa ou desassocia o EIP da instância
      • Atacha ou detacha o ELB a uma layer
    • Útil por exemplo pra configurar o proxy, service discovery, etc
  • Deploy = Ocorre quando é executado o comando Deploy, geralmente pra entregar uma aplicação para as instâncias do servidor
    • Setup executa deploy depois de terminar
  • Undeploy = Ocorre quando é executado o ocmando Undeploy ou quando um app é deletado. Cleanup
  • Shutdown = QUando desliga uma instância, mas antes de parar a instância EC2. Executar cleanup
    • Configure executará após

Auto Healing

  • Unhealthy = Agent não consegue se comunicar com o OpsWorks em 5 minutos
  • EBS backed instance = Stop && start
  • Notificação = CloudWatch Events
    • Instance state change, statuses connection_lost, start_failed, stop_failed
    • Eventos disponíveis
      • Instance state change
      • Command state change
      • Deployment state change
      • OpsWorks alert
      • API call via CloudTrail

Domain 3: Monitoring and Logging

(Por enquanto apenas os principais pontos)

CloudTrail

Log Integrity

  • Hacker pode mudar o conteúdo do arquivo CloudTrail
  • Verificar integridade com CLI (modificação ou exclusão de digest ou arquivos)
  • aws cloudtrail validate-logs
    • Start time
  • Digest entregue 1x a cada hora

Cross Account Logging

  • Múltiplas contas entregando nos mesmos buckets S3
  • Bucket policy para múltiplas contas
  • Permitir outras contas para lerem = Atachar IAM Role ou Access Policy
  • Permitir apenas o prefixo da sua conta para leitura
  • Possível permitir organization também

Kinesis

  • Real-time insights e dashboards
  • Alternativa gerenciada ao Kafka (não possui mesma API)
  • Logs, métricas, IoT, clickstreams, big data "real time"
  • Replicação para 3 AZs
  • Tipos de serviços
    • Kinesis Streams = streaming de baixa latência com escala
    • Analytics = Análise real-time com SQL
    • FireHose = Carregar streams no S3, Redshift, ElasticSearch
  • Possível integrar -- Streams -> Analytics -> Firehose -> S3

Kinesis Streams

  • Streams divididas em shards / Partições
  • Producers => Shard 1/2/3 => Consumers
  • Retenção de 1 dia por default, mas pode ir até 7 dias
  • Pode reprocessar / repetir dados
  • Múltiplas aplicações podem consumir a mesma stream
  • Real-time processing
  • Dados são imutáveis (não podem ser excluídos) depois de inseridos
  • Shards
    • Billing por shard provisionado, dá pra ter quantos forem necessários
    • Batching disponível ou chamadas por mensagem
    • Número de shards pode evoluir com o tempo (reshard ou merge)
    • Shard = Throughput
    • Registos ordenados por shard
  • Records
    • Data blob: dados enviados, serializados como bytes. Até 1MB
    • Record key: ajuda a agrupar registros em shards -- Mesma chave = mesmo shard
      • Usar chave distribuída para evitar "hot partitions"
    • Sequence number: UUID para os registros colocados no shard. Adicionado pelo Kinesis
  • Limites
    • Producer
      • 1MB/s ou 1000 mensagens/s de escrita POR SHARD
      • Hot Shard = ProvisionedThroughputException
    • Consumer Classic
      • 2MB/s de leitura POR SHARD entre todos os consumers
      • OU 5 Api calls por segundo entre todos os consumers
      • Se 3 aplicações diferentes estão consumindo, possível throttling
    • Data retention
      • 24 por default
      • Aumentar até 7 dias
  • Producers
    • Kinesis SDK
    • Kinecis Producer Library (KPL)
    • Kinesis Agent
    • CloudWatch Logs
    • 3rd party -- Spark, Log4J, Flume, Kafka Connect, NiFi, etc
  • Consumers
    • Kinesis SDK
    • Kinesis Client Library (KCL)
      • Importante!
      • Usa DynamoDB para fazer checkpoint de offsets
      • Registra outros workers e compartilhar o trabalho entre shards
      • Ótimo para leitura distribuída
      • Não pode ter mais KCL apps que shards
    • Kinesis Connector Library
    • Firehose
    • Lambda (ex. inserir no ElasticSearch)
    • 3rd party -- Spark, Log4J, Kafka Connect, etc

Data Firehose

  • Não precisa de administração
  • Near real time (latência de 60 segundos para batches não completos)
  • Carregar dados no Redshift / S3 / ES / Splunk
  • Autoscaling
  • Transformação de dados com lambda (ex CSV => JSON)
  • Suporta compressão para o S3 (GZIP, ZIP, Snappy)
  • Não possui armazenamento
  • Paga pela quantidade de dados passando pelo Firehose
  • Converte JSON para Apache Parquet ou Apache ORC, mais eficiente de fazer queries que JSON
  • S3 buffer
    • Buffer size
    • Buffer interval
  • Inputs
    • KPL
    • Agent
    • Streams
    • CW Logs & Events
    • IoT
  • Transform = Lambda
  • Outputs
    • S3
    • Redshift
    • ES
    • Splunk
  • Diferença entre Streams para armazenamento
    • Realtime = Streams
    • Near realtime = Firehose

Data Analytics

  • Real-time analytics em Streams usando SQL
  • Autoscaling, gerenciado, contínuo
  • Paga pelo que entra
  • Possível criar streams a partir das queries
    • Jogar de volta pro Streams ou Firehose

CloudWatch

Metrics

Metrics to Know

  • EC2
    • CPUUtilization
    • NetworkIn/Out
    • Status check failed
    • CPU Credit Usage/Balance
    • RAM, Processes, Disk Usage = CloudWatch Agent
  • EBS
    • Read & Write Bandwidth
    • Throughput
    • Queue Length = Quantas operações agendadas -- Muito grande = ruim
    • Time spent idle = Quanto tempo o disco ficou parado -- Muito grande = bom
  • ASG
    • Min/Max/Desired
    • Instances InService/Pending/Standby/Terminating
    • Ativar Group Metrics Collection
  • ALB
    • TargetResponseTime
    • Requests
    • Errors
    • ELB Errors
    • Target connection erorrs
    • Active connection count
    • Consumed Load Balancer Capacity Units = Forma que a AWS vai te cobrar
      • Quanto mais usar, mais caro fica
  • RDS
    • CPUCredit
    • DatabaseConnections
    • BinLogDiskUsage
    • Memory
    • R/W IOPS
  • Estudar métricas dos serviços pra saber quando você precisa criar uma custom metric

CloudWatch Logs

  • Export to S3
    • Console = Actions > Export data to Amazon S3
      • From Date X to Date Y
      • Stream prefix
      • Destination
      • Bucket permissions
      • Tasks, pode levar um tempo para finalizar
    • Automação = CloudWatch Events
      • Solução 1: Invocar a lambda a cada X vezes para chamar a API
      • Logs subscription para real-time

Log Subscription

  • Processamento dos logs em tempo real
  • Entrega para 3 serviços
    • Kinesis Stream
    • Data Firehose Stream
    • AWS Lambda
  • Kinesis não dá pra fazer via Console
  • CW Logs -> Lambda
    • Lambda recebe dados em real-time
    • Fazer o que vc quiser (ES, Splunk, etc)
  • CW Logs -> Firehose
    • Near-realtime (Buffer)

Kinds of logs

  • App logs = Produzidos pela aplicação
    • Mensagens, traces, etc
    • Escrito no FS local -> Enviado para o CloudWatch Logs
  • OS Logs
    • Event logs, System logs. Comportamento do sistema
    • Gerados pelo sistema
    • /var/log/messages ou /var/log/auth.log
  • Access logs
    • Lista de todos os requests feitos em um site
    • /var/log/apache/access.log
  • AWS Managed logs
    • Load balancer access logs => To S3
    • CloudTrail Logs => To S3 ou CW Logs
    • VPC Flow Logs => To S3 ou CW Logs
    • Route53 Access Logs => To CloudWatch Logs
    • S3 Access Logs => To S3
      • Quem acessou requests para o S3 bucket
    • CloudFront Access Logs => To S3

CloudWatch Events

  • EventBridge = CW Events "rebranded"
    • Eventos externos para o CW Events
    • Service Partners
  • Schedule
    • Fixed rate ou Cron expression
  • Event Pattern
    • Reagir a eventos dos serviços AWS
    • Ex. CodePipeline Execution State Change -- State FAILED
    • Documento JSON
  • Target
    • Acionado quando o evento ocorrer
    • Mais comum: Lambda function
    • Exemplos:
      • Batch job queue
      • CW Log group
      • CodeBuild / CodePipeline
      • EC2 action
      • ECS task
      • Firehose delivery stream
      • Lambda / Step Functions
  • S3 eventns
    • Bucket level operations
    • S3 object level operations = CloudTrail para o bucket
  • Quando o evento não está na lista dos suportados = CloudTrail
    • AWS Api Call via CloudTrail
    • Disponível para quase todos os serviços
    • Apenas read/write
      • List, Get ou Describe não suportados
{
  "source": [
    "aws.ec2"
  ],
  "detail-type": [
    "AWS API Call via CloudTrail"
  ],
  "detail": {
    "eventSource": [
      "ec2.amazonaws.com"
    ],
    "eventName": [
      "CreateImage"
    ]
  }
}

S3 Event Notifications

  • S3 Events, não CloudWatch Events
  • Properties -> Advanced SEttings -> Events
  • Send to
    • SQS (Precisa adicionar policy no SQS)
    • SNS
    • Lambda function

AWS X-Ray

  • Coleta informações sobre requisições da aplicação
  • Fornece ferramentas para visualizar, filtrar e obter insights para identificar problemas e oportunidades para otimização
  • Componentes
    • Daemon executando na máquina
    • SDK para instrumentar a aplicação
    • API para receber as informações do Daemon
    • Console para visualizar
  • Service Map
    • AWS Mapeando o que está acontecendo com a infraestrutura
  • Automation
    • CW & SNS para notificar altos níveis de latência, erros e falhas na aplicação
    • CW Event - Scheduled trigger
    • Lambda function - call the GetServiceGraphAPI para o X-Ray
    • Se tiver algo errado, notificar via SNS

CW Dashboards

  • Cross region (métricas de outra região são mantidas)
  • Correlation = Forma que a AWS chama = CW Dashboards
  • Service Dashboards = Dashs que a AWS cria pra você, com as métricas prontas

ElasticSearch (ES)

  • ES Gerenciado
  • Rodar em servidores (não existe serverless ES)
  • Use cases: Análise de logs, monitoramento, análise de segurança e clickstream, indexing
    • Search ou Dashboards = ótimo candidato
  • ELK Stack
    • ElasticSEarch = search e indexing
    • Kibana = real-time dashboard no topo do ES
      • Alternativa ao CW Dashboards
    • LogStash = Mecanismo de ingestão de logs ("Logstash agent")
      • Alternativa ao CW Logs (você decide retenção e granularidade)
  • Patterns
    • DynamoDB Table
      • API para retornar itens
      • Scan é ineficiente para buscas
      • Solução: DynamoDB Stream -> Lambda -> ElasticSearch
      • Criar uma API na frente do ES para procurar por itens
    • CloudWatch Logs
      • Subscription Filter
      • Lambda Function, envia em tempo real para o ES
      • Kinesis Data Firehose, envia em near real-time para o ES (mais barato)

Cross account logging

  • Kinesis Streams é o único destino suportado para cross-account subscriptions
  • Log data sender = Pega a informação de destino e avisa o CW Logs que está pronto pra mandar os log events
  • Log data recipients = Destino (Kinesis Stream) e avisa o CW Logs que o recipiente quer receber dados dos logs
  • Criar destination
    • aws kinesis create-stream
    • IAM Role dando permissão para o CloudWatch Logs enviar dados para o Kinesis Stream
    • aws logs put-destination
    • Adicionar destination policy permitindo a conta de origen enviar
  • Criar subscription filter
    • aws logs put-subscription-filter
      • destination -> Destination criado acima

Hands on

  • Streaming CW Logs to ElasticSearch

Tagging in AWS

Domain 4: Policies & Standards Automation

SSM

  • Gerenciar sistemas EC2 e On-premises
  • Windows e Linux
  • Insights sobre a infra
  • Automação de patching = Ouviu falar de patching geralmente vai ser SSM
  • Integrado com AWS Config
  • Free
  • Serviços e features
    • Resource Groups (Agrupar recursos)
    • Insights
      • Insights Dashboards
      • Inventory: Descobrir e auditar software instalado
      • Compliance
    • Parameter store
    • Automation (desligar EC2, criar AMIs)
    • Run Command
    • Session Manager (SSH)
    • Patch Manager (atualizar e gerenciar estado)
    • Maintenance window (patch e comandos no horário certo)
    • State Manager (definir e manter config de OS e apps)
  • Instalação de um agent nos sistemas que queremos controlar
  • Instância não pode ser controlada via SSM = Problema com o agent ou IAM Role

Managed Instances

  • Instâncias gerenciadas pelo SSM
  • Instalar o agent e conectar à internet
  • Activation code e ID, tipo access key
  • Permitem que as instâncias on-prem assumam uma role especificada

Resource Groups

  • Agrupar recursos
    • Por tag
    • Por stack CFN
    • Utilizado nos outros recursos do SSM

Run Command

  • Documents = Instruções para serem executadas
  • Documentos da AWS ou criar próprios
  • JSON
  • Compartilhar
  • Tipos
    • Command = Usados no Run Command
    • Automation = Usados no SSM Automation
    • Policy = Reforçar políticas em instância - ex AWS-GatherSoftwareInventory
    • Session = Dizer que tipo de sessão iniciar (port forward, comando, ssh tunnel)
  • Command parameters
  • Targets
    • Especificar tags
    • Escolher instâncias manualmente
    • Resource Groups
  • Rate control
    • Concorrência (Quantas instâncias ou %)
    • Error threshold (Quantos erros ou %)

Parameter Store

  • Padrão /aplicação/env/parametro
  • Parameter Type
    • String/StringList = Texto plano, valores não-sensíveis como URL do banco
    • SecureString = Criptografado com chave KMS
  • Histórico dos valores e quem alterou = audit trail
  • aws ssm get-parameters --names /foo/bar --profile foobar --with-decryption
  • aws ssm get-parameters-by-path --path /my-app/dev --recursive

Patch Manager

  • Patch baselines = definidas pela AWS, para vários sistemas,
  • Approval rules = Regras para especificar alguns tipos de patches que são aprovados automaticamente
    • Selecionar por produto (Distributor), Severidade, Classificação (Security, Bugfix, etc)
    • Auto approval após data ou X dias
    • Nível de severidade para compliance report
    • Incluir nonsecurity updates
  • Exceptions
    • Approved ou Rejected patches
  • Updates vêm diretamente da Amazon
  • Custom Baseline permite adicionar fontes diferentes
  • Executar na janela de manutenção = Run Task
    • AWS-RunPatchBaseline
    • Scan (saber sobre compliance) ou Install (instalar patches)

Maintenance Window

  • Executar patches
  • Cron ou Rate expression
  • Permite setar duração da janela, e quantas horas antes de encerrar a janela deve parar de iniciar tarefas
  • Data de início e término da janela
  • Timezone da janela
  • Registra várias tasks dentro da janela
    • Run Command
    • Automation = Criar AMIs
    • Lambda = Triggar ações adicionais, como verificar as instâncias por patch updates
    • Step Function = Rodar state machines para ações complexas, como remover a instância do ELB, patchear e adicioná-la de volta
  • Maintenance window não tem overlap

Inventory

  • Coisas rodando dentro das instâncias na conta
    • Aplicações
    • Componentes da AWS (agent SSM, CW logs, etc)
    • Network config
    • Windows Updates
    • Informações detalhadas da instância (modelo de CPU, velocidade, cores, etc)
    • Serviços (Windows only)
    • Windows Roles
    • Custom Inventory
    • Billing info (licensas)
    • Arquivos dentro da máquina
    • Registro do Windows
  • Sync execution logs em um bucket s3

SSM Automation

  • Automatizar manutenção e deployment de instâncias e outros recursos
  • Notificações via CloudWatch Events
  • Monitorar progresso e detalhes (audit) via console
  • Use cases comuns
    • AWS-StopEC2InstanceWithApproval para parar uma instância EC2 após a aprovação de um ou mais usuários IAM
    • AWS-StopEC2Instance - parar instâncias automaticamente em uma agenda (CW Events) ou usando uma Maintenance Window
    • AWS-UpdateCloudFormationStackWithApproval - atualizar recursos do ClloudFormation com aprovação
    • Realizar tarefas disruptivas em lote
      • AWS-RestartEC2InstanceWithApproval - Especificar número de erros ou concorrência
    • Criar golden AMI - AWS-UpdateLinuxAMI, incluindo ou excluindo pacotes para serem instalados
    • Resgatar instância EC2 danificada - AWSSupport-ExecuteEc2Rescue
  • Criação de Golden AMI
    • launchInstance: Iniciar instância com userdata para instalar o SSM Agent e IAM Role
    • updateOSSoftware: Baixa script do S3, executa scripts antes e depois, atualiza pacotes e Amazon software
    • createImage: Gera uma AMI
    • terminateInstance
  • CloudWatch Events = Execution Status Change notification
    • Filtrar por status
    • Executar AWS inspector
  • AMI ID -> Parameter Store
  • Possível adicionar um passo de aprovação manual -> SNS

Session Manager

  • SSH Gerenciado
  • Auditoria de quem executou a sessão
  • Possível mandar comandos executados para o S3

AWS Config

  • Compliance e mudanças over time
  • Include global resources - IAM
  • Bucket = Configuration history e snapshots
  • SNS = Stream de TODAS as config changes e notificações
    • Use case: insights operacionais sobre o que está rolando no Config
  • Sem nenhuma regra, serve como um registro de todas as configurações
    • Timeline de mudanças nas configurações
  • Relacionamento com outros recursos (ENI, SG, Subnet, etc)
  • Eventos do CloudTrail relacionados àquela instância
  • Backup de configuração via documento JSON

Config Rules

  • Audit trail, garantir compliance
  • Forte integração com CW Events
  • Cada regra = $1/mês
  • Regras interessantes
    • Expiração de certificado ACM
    • ALB redirecionando HTTP para HTTPS
    • CloudTrail enabled
    • CloudTrail KMS CMK Encryption
    • CloudTrail Log File Validation
    • CloudWatch Log Group criptografado
    • DynamoDB Table Encrypted
    • EC2 EBS Encrypted
    • EC2 instance managed by SSM
    • EFS KMS Encryption
    • EIP Attached
    • Disallow Unrestricted SSH
  • Custom Rules
    • Lambda function ARN
    • AWS Config Blueprint
  • Trigger Type
    • Configuration change = Acionado sempre que houver uma mudança nos recursos monitorados
    • Periodic = Executado a cada X minutos
    • Dá pra ter os dois
  • Escopo
    • Recursos
    • Tags
    • Todas as mudanças

Automation

  • Remediação das regras = Integração com CloudWatch Events
  • Sempre que uma regra tem um problema, ela manda pro CW Events
  • Target = Lambda Function, Step Function, SSM Automation, Terminate Instance
  • Remediation dentro da rule (2019)
    • Usa SSM Automation

Multi Account/Multi Region

  • Aggregator = Recurso do config que coleta dados de compliance e configuração
    • Multi regions
    • Multi accounts
    • Organization

AWS Service Catalog

  • Usuários novos podem criar stacks não-compliant ou em desacordo com o resto da organização
  • Portal Self-service que permite lançar produtos pré-definidos
    • VMs pré configurados, bancos de dados
  • Admin
    • Product = CloudFormation Template
    • Portfilio = Collection of products - Can be seen as teams
    • Control = IAM permissions para acessar os portfólios
  • User
    • Product list no portal self service, garantido pelo IAM
    • Launch
    • Produtos provisionados, configurados e taggeados da forma correta
  • Criar e gerenciar catálogos de serviços IT aprovados na AWS
  • Produtos = CloudFormation templates
  • VMs, servers, software, databases
  • Integração com portais self-service como ServiceNow
  • Criar produto -> Vincular a um portfolio
  • Portfolio
    • Vincular usuários que podem acessar
    • Vincular constraints
    • Compartilhar com outras contas ou organizations
  • Launch product vira "Provisioned product"
    • Possui produto de referência e versão
    • Parâmetros
  • TagOptions adicionada pelo administrador
  • Notificações do produto enviadas para um tópico do SNS

Inspector

  • Análise de segurança de EC2
  • Instalar o Inspector Agent (dá pra automatizar via SSM)
  • 2 tipos de assessments
    • Network Assessments (Não precisa do agent)
      • Portas acessíveis de fora da VPC
      • Se tiver o agent, também descober processos escutando nas portas
    • Host Assessments (Precisa do agent)
      • Software vulneráveis (CVE), hardening do host (benchmarks CIS), boas práticas de segurança
  • Todas as instâncias ou especificar por tag
  • Rules packages - Pacotes de vulnerabilidades que a AWS vai procurar
  • Recorrência (schedule) - Cria CloudWatch Event
  • Inspector will never launch an instance for you
  • Install agents with Run Command
  • Após executar
    • Lista de findings, download em pdf ou html
    • Filtrar os findings no console

Inspector Automation

  • Integração com CloudWatch Events
  • Adicionar schedule
  • Inspector Assessment template é um target no CloudWatch Events
    • Quando uma EC2 ficar em Running (evento), executar o assessment
  • Template enviar mensagens para um tópico SNS
    • Run started, Run finished, Run state changed, Finding reported
    • Atualmente não dá pra pegar esses eventos via CloudWatch Events
  • Auto remediation
    • Subir uma EC2 com o SSM Agent
    • Instalar o Inspector agent usando SSM
    • Criar um tópico SNS onde o Inspector irá publicar mensagens
    • Configurar o Assessment Template para publicar as notificações em um tópico SNS
    • Criar uma Lambda pra ser acionada pelas notificações que irá usar o SSM para fazer remediação automática na instância
  • Golden AMI Assessment
    • Scheduled CW Event
    • Lambda function launch EC2 instance
    • Start Inspector Assessment
    • Notifications on SNS Topic
    • Trigger Findings Lambda Function
    • Call SNS back

EC2 Instance Compliance

  • AWS Config
    • Garantir configuração da AWS própria
    • Ruleset pra avaliar a configuração contra os seus padrões
    • Security group, tamanho da instância, etc
    • Auditoria e compliance com o tempo
  • Inspector
    • Scans de segurança dentro do OS
    • Scans de rede por fora (não precisa do agent)
    • Não sobe a EC2 pra você, análise baseada em tags
  • Systems Manager
    • Automação, patches, comandos, inventário (sw instalado)
  • Service Catalog
    • Self-service
    • Restringir como as instâncias são lançadas pra minimizar configurações
    • Útil para onboarding de novos usuários da AWS
  • Configuration Management
    • SSM, OpsWorks, Ansible, Chef, Puppet, User Data
    • Garantir configuração correta das EC2

Health

Service Health Dashboard

  • Dashboard com informação de todos os serviços e seu estado, e histórico de problemas
  • RSS feed

Personal Health Dashboard

  • Event log relacionados ao seu uso da AWS (todas as regiões)
  • Lista de recursos afetados na conta
  • Dashboard com os problemas
  • Mudanças agendadas (ex. AWS precisa terminar uma instância, te dão 7 dias pra terminar vc mesmo)
  • CloudWatch Events - Notificações
    • Service Name = Health
    • Serviços e notificações específicas
  • Notificação para AWS_RISK_CREDENTIALS_EXPOSED
    • AWS busca por credenciais expostas no GitHub
    • Automação
      • CW Events
      • Step Functions
      • Lambda -> Remover usuário IAM
      • Lambda -> Analisar chamadsa CloudTrail
      • Lambda -> SNS com sumário
      • Step functions > Lambda pois pode enviar notificação mesmo em caso de erro
        • Maior rastreabilidade e auditabilidade

Trusted Advisor

  • Automatizar notificações de limites
  • Refresh 1x a cada 5 minutos
  • Recomendações de custo, performance, segurança, tolerância a falhas e limites de serviços
  • Também possui notificação para exposed access keys
  • Service limits = Aviso em 80%
  • Possível desativar o Trusted Advisor
  • Possível ativar e-mail semanal
    • Para contato de billing, operações e segurança

Trusted Advisor - Automations

  • Integrar com CloudWatch Events
    • Precisa criar a regra em N. Virginia pois o Trusted é um serviço global!
  • https://github.com/aws/Trusted-Advisor-Tools
    • Parar EC2 com baixa utilização
    • Criar snapshots para volumes sem backup recente
    • Deletar chaves IAM expostas e monitorar uso
    • Ativar versionamento em bucket
  • Premium support = Métricas do Trusted Advisor no CloudWatch
    • CW Alarms para limites
  • Automatizar refresh
    • aws support refresh-trusted-advisor-check
    • describe check refresh statuses
    • describe check result
    • describe check summaries
    • describe checks
    • Precisa do suporte premium :(

GuardDuty

  • Descoberta de ameaças automatizada para proteger sua conta
  • Machine learning, anomaly detection, etc etc
  • Não é barato
  • Inputs
    • CloudTrail logs
    • VPC Flow Logs
    • DNS Query Logs
  • Notifica em caso de problemas
  • Integra com AWS Lambda
  • Ativar = Criar service role
  • Free trial = Custo diário estimado
  • Findings
    • EC2 minerando bitcoins
    • Bruteforce na EC2
    • Trojan
  • Automação = CloudWatch Events
    • GuardDuty -> GuardDuty Finding
    • Notificações

Amazon Macie

  • Analisar dados no S3 e garantir que os dados classificados estão protegidos
  • Service tokens, private keys, CC data
  • Service role
  • Escolhe quais buckets
  • CloudTrail activity para o arquivo
  • Multi accounts

Secrets Manager

  • Rotacionar, gerenciar e obter secrets
  • Diferença do Parameter Store
    • Rotação
    • Integrado com RDS e Postgres
    • Mais fácil de usar
  • Credenciais para DB (RDS, Redshift, DocDB, etc) -> User/Password
    • Possível linkar com qual database irá usar
  • Outras credenciais = Key/value pairs
  • KMS encryption key
  • Rotação
    • Lambda function com permissões para rotacionar o secret

License Manager

  • Gerenciar licenças de software (MS, Oracle, SAP)
  • Monitorar uso, inventário, alertar usuários
  • License type
    • vCPUs
    • Cores
    • Sockets
    • Instances
  • Associar com recursos ou AMIs
    • Sempre que uma instância estiver rodando com aquela AMI, uma licensa vai ser consumida

Cost Allocation Tags

  • Para as tags aparecerem nos relatórios de custo, temos que identificar como Cost Allocation Tags
    • Aparecerão como colunas nos cost reports
  • AWS Generated Cost Allocation Tags
    • Começam com o prefixo aws: (aws:createdBy)
    • Aplicadas automaticamente
    • Não serão aplicadas aos recursos antes da ativação do Cost Allocation Tags
  • User tags
    • Definidas pelo usuário
    • Começam com o prefixo user:
  • Aparecem apenas no billing console

Data & Network Protection

  • In transit

    • TLS
    • ACM para gerenciar certificados
    • Load balancers = SSL Termination
    • Criptografia SSL/TLS opcional entre o ALB e as EC2 -- mas é recomendado pra ficar com segurança top
    • CloudFront com SSL
    • Todas os serviços expõem endpoints HTTPS
    • Único que expõe HTTP é o S3, mas vc não deveria usar isso

  • At rest

    • S3
      • SSE-S3 = Chave da AWS
      • SSE-KMS = Nossa chave do KMS
      • SSE-C = Chave própria
      • Client-side = Enviar conteúdo já criptografado
      • Default encryption nos buckets
      • Reforçar encryption através de policy (x-amz-server-side-encryption)
      • Glacier encrypted by default
    • EBS, EFS, RDS, ElastiCache, DynamoDB, etc
      • Tick a box
      • Service key ou própria chave KMS

  • Categoria de dados

    • PHI = Protected health information
    • PII = Personally-identifying information

  • Network protection

    • Direct Connect
    • Public internet: VPN
      • Site-to-Site VPN c/ TLS -- IPsec
    • Network ACL: Firewall Stateless
    • WAF + Shield: Regras contra exploits
    • Security Groups: stateful firewall no hypervisor da instância
    • System firewalls na EC2 -- Windows

Domain 5: Incident and Event Response

  • Troubleshooting, restaurar operações
  • Automatizar gerência de eventos e alertas, configurar ações automatizadas orientadas a eventos
  • Automated healing: CloudWatch, BeanStalk, OpsWorks, AutoScaling

AutoScaling Groups

  • ASG = Advanced Details = Receive traffic from one or more load balancers
  • Launch configurations = Criar instâncias como parte do ASG
  • Launch templates = Forma nova, avançadas
    • Usar tanto on-demand quanto spot, no mesmo template
    • Pode ser atualizado o mesmo, criando uma nova versão (ao contrário da launch configuration)
    • Source template (parents)
    • Instance type = opcional - se não definir será colocado na hora de lançar a instância
    • Template tags <> Instance tags
    • Usando o template = Criar EC2, ASG ou Spot Fleet
  • Criar ASG com Launch Template = Combinar purchase options & instances
    • Colocar peso para cada tipo de instância e mínimo (qtd e %) on-demand
  • Scheduled Actions = Min, Max, Desired a cada X períodos (ou "Once"), start time
  • ASG Health Check Type
    • EC2 = Status checks da instância
    • ELB = Health check do load balancer. Grace period = segundos pra ignorar o healthcheck enquanto a instância sobe
  • Vincular ALB = adicionar Target Group no ASG
    • Slow start = Adicionado no Target Group, rampa para o ALB começar a enviar tráfego em vez de mandar tudo de uma vez
    • 30 a 900 segundos, ou 0 para desabilitar
  • Detach instance = desatachar uma instância e ELBs associados. Adiciona outra no lugar no ASG
  • Standby = Remove do ELB, mas não do ASG. Não adiciona outra no lugar
    • InService = Adiciona de volta ao ELB
  • Scale in protection = Evita que instância seja removida em um scale in
  • Termination Policy
    • Default ou personalizada, dá pra colocar mais de uma policy
    • Default
      • Qual AZ tem mais instâncias e que pelo menos uma não está protegida de scale in
      • Launch template: Verificar allocation strategy (mix de on-demand e spot)
      • Instância que tem o launch template/configuration mais antigo
      • Instância mais próxima de ter uma hora fechada de billing
      • Random
    • OldestInstance = Mata a instância mais antiga (tempo de lançamento) no grupo
      • Fazer upgrade de instâncias para um novo tipo
    • NewestInstance = Mata a instância mais nova
      • Testar um launch configuration novo e não quer mantê-lo em produção
    • OldestLaunchConfiguration = Launch configuration + antigo
    • ClosestToNextInstanceHour = Próximo de 1 hora redonda
    • OldestLaunchTemplate = Launch template + antigo
    • AllocationStrategy = Com base no mix de spot e on-demand
    • Default usando os nomes dos tipos:
      • AllocationStrategy
      • OldestLaunchConfiguration / OldestLaunchTemplate
      • ClosestToNextInstanceHour
  • Integração com SQS
    • Escala com base no tamanho da fila = Custom metric emitida pela aplicação
    • Evitar terminate da instância enquanto está processando msg
      • Proteger de scale-in no ASG
      • Aplicação chama a API toda vez que pegar uma mensagem da fila pra processar
  • Integração com CodeDeploy
    • Quando criar um deployment no CodeDeploy, sempre que o ASG criar uma instância, o CodeDeploy vai fazer o deploy nela
    • Blue/Green = Copiar o ASG
    • Se houver um scale-up durante um deployment, o CodeDeploy irá aplicar a versão antiga da aplicação na nova instância
    • Suspender Launch durante o deploy (apenas para in-place)
  • Monitoring
    • Métricas a nível de grupo
    • Métricas a nível de EC2 (média entre as instâncias)
    • Notificações para SNS
      • launch
      • terminate
      • fail to launch
      • fail to terminate
    • CloudWatch events para mais flexibilidade
      • launch
      • terminate
      • fail to launch
      • fail to terminate
      • Launch/Terminate lifecycle action

Scaling Policies

  • Default cooldown = Número de segundos entre uma atividade de escala (up ou down) e outra
    • Valor baixo = muitas instâncias
    • Default = 300
  • Warm-up after scaling = Quanto tempo que a instância precisa até começar a considerar as métricas dela no alarme
  • Disable scale-in = ASG não irá dar um terminate na instância
  • Target tracking = cria automaticamente o AlarmHigh e AlarmLow no CloudWatch Alarms, gerenciado pelo ASG
  • Simple policy = vinculada a um alarme, adiciona X instâncias e espera Y segundos antes de permitir outra atividade
  • Step policy = Parecida com a simple, mas permite adicionar mais de uma ação com base no threshold
    • Adicionar 1 instância quando AlarmFoo estiver entre 1 e 25
    • Adicionar 2 instâncias quando AlarmFoo estiver entre 25 e 70
    • Adicionar 3 instâncias quando AlarmFoo for maior que 70

Suspending Processes & Troubleshooting

  • Recomendação = Usar StandBy e Scale-in Protection caso seja necessário fazer troubleshooting ou reiniciar uma instância
  • Suspended Processes
    • Launch = Criação de novas instâncias pra suprir a desired capacty
      • Ao suspender = Se aumentar a desired capacity, novas instâncias não serão lançadas
      • Use case = Troubleshooting, garantir que o ASG fique em um det. tamanho
    • HealthCheck = Alteração do status da instância para healthy/unhealthy
      • Ao suspender = Status da instância não será alterado
      • Use case = Se a instância está unhealthy mas você quer mantê-la (ex. troubleshooting ou HC mal configurado)
    • ReplaceUnhealthy = Substituição de instâncias unhealthy (terminate)
      • Ao suspender = Instâncias unhealthy não serão substituídas
      • Use case = Troubleshooting de instâncias não saudáveis
    • AZRebalance = Se tiver muitas instâncias em uma AZ, rebalancear elas para distribuir
      • Ao suspender = Instâncias não serão rebalanceadas
      • Use case = Evitar interrupções no serviço
    • AlarmNotification = Recebe notificações dos alarmes do CloudWatch Alarms
      • Ao suspender = scaling policies baseadas em alarme não irão mais responder aos eventos
      • Use case = problema com alarme, troubleshooting
    • ScheduledActions = Processo de ações agendadas
      • Ao suspender = instâncias não serão mais alteradas pelo ScheduledActions
      • Use case = Cliente quer desabilitar por um tempo
    • AddToLoadBalancer = Adiciona instâncias no Load Balancer / Target Group
      • Ao suspender = Instâncias não serão adicionadas no ELB
      • Ao voltar, tem que adicionar as instâncias manualmente

AutoScaling Hooks

  • Fluxo = Pending -> InService -> Terminating -> Terminated
  • Fluxo com hooks = Pending -> Pending:Wait -> Pending:Proceed -> InService -> Terminating -> Terminating:Wait -> Terminating:Proceed -> Terminated
  • EC2_INSTANCE_LAUNCHING
    • Instalar e configurar uma aplicação que vai demorar um pouco
  • EC2_INSTANCE_TERMINATING
    • Antes de terminar, pegar os logs e jogar no S3, ou fazer um snapshot do EBS
  • Como chamar os hooks
    • SNS
      • Precisa ter algo (tipo uma EC2) pra receber as notificações
    • SQS
      • Legado, precisa ter uma EC2 pra receber as mensagens
    • Lambda / CloudWatch Events
      • Recomendado
  • Hearbeat Timeout = Se eu não tiver notícias da instância por X segundos, considerar o hook como DEFAULT_RESULT
    • DEFAULT_RESULT = ABANDON ou CONTINUE
    • Máximo = 2 horas
    • Dá pra resetar e ficar infinito
  • Rodar os comandos dentro da EC2 = Possível, usando SSM Run Command

CloudFormation x ASG

  • CreationPolicy
    • Garantir que as instâncias foram criadas corretamente
    • ResourceSignal = Instâncias vão sinalizar que estão vivas
    • Count = número do DesiredCapacity idealmente
    • Timeout = PT15M = 15 minutos
    • Precisa usar cfn-signal na launch configuration
  • UpdatePolicy
    • Se mudar apenas a Launch Configuration, por padrão não irá alterar as instâncias rodando
    • Aplicável a AutoScalingGroup, Lambda::Alias e ElastiCache::ReplicationGroup
    • AutoScalingRollingUpdate
      • MinInstancesInService = quantas instâncias
      • MaxBatchSize = Tamanho máximo do lote de instâncias pra atualizar de uma vez
      • PauseTime = Tempo para aguardar até executar o próximo batch
      • WaitOnResourceSignals = PauseTime vira o tempo para esperar até receber os signals
    • AutoScalingScheduledAction
      • Quando o recurso possui uma Scheduled Action habilitada
      • IgnoreUnmodifiedGroupSizeProperties = Evitar conflito com scheduled actions durante o update
    • AutoScalingReplacingUpdate
      • Cria um novo ASG e substitui
      • WillReplace = true

DynamoDB

  • Primary Key
  • Secondary Indexes
    • Usados quando as queries baseadas na Primary Key não são eficientes
  • Local Secondary Index / LSI
    • Precisa ser definido quando cria a tabela
    • Quando você quer usar uma SortKey diferente da definida na tabela
    • Precisa usar a mesma Partition Key
  • Global Secondary Index
  • Pode definir quando cria a tabela ou depois
  • Pode ter Partition Key e (opcionalmente) Sort Key diferentes
  • Precisa ter RCU e LCU
  • Provisioned Capacity
    • Auto Scaling = AWS garante a escala de RCU e LCU com um target utilization, min e max
      • Dá pra aplicar a mesma configuração para GSIs
    • Workload mais previsível / estável
  • On-demand
    • Mais caro
    • Workload instável
  • RCU e WCU formulas
  • Encryption at rest
  • Hot items
    • DAX = Cache
    • Cria um cluster, você faz as queries no cluster em vez de fazer no Dynamo
  • Streams = Eventos quando forem alteradas coisas do cluster
    • Keys only = apenas as chaves do que foi modificado
    • New image = o novo objeto
    • Old image = o objeto antigo
    • New & old images
    • Ligar com uma lambda na stream
    • Por baixo dos panos = kinesis streams
    • Throttling issues
      • Kinesis tem limites de reads e writes em cada shard
      • 2 processos lendo, OK. 3 ou mais pode dar problema
      • 1 lambda lendo e gravando em um SNS
  • Global Tables
    • Tabela precisa estar vazia e DynamoDB Streams deve estar ativado
    • Replica os dados em outra região
  • Time to live attribute
    • Coluna na tabela que vai dizer quando ele deve expirar
    • Ativar no console na tabela
    • TTL tem que ser um epoch timestamp
  • Dynamo Patterns
    • S3 write -> Lambda -> Metadados do objeto no Dynamo
      • API para os metadados => Procurar por data, storage utilizado, objetos com atributos, objetos enviados em um range
    • DynamoDB Table -> Stream -> Lambda -> ElasticSearch
      • Permite procurar por itens

S3

  • Events = PUT, POST, COPY, Multipart completed, all obj create, obj in RRS lost, perm deleted, del marker created, all delete evts, restore initiated, restore completed
    • Prefix, suffix
    • Send to = SNS, SQS, Lambda
    • CloudWatch Events = precisa do CloudTrail habilitado
  • Cross Region Replication
    • Cross account tbm
    • Bucket inteiro ou um prefixo ou tags
    • Replicar os objetos encriptados com KMS (pode atingir o limite de requisições)
    • Same Region Replication (feature nova, provavelmente não cai na prova)
    • Mudar classe de armazenamento e ownership
  • Lifecycle
    • Current objects and previous objects
    • Expire objects after X days
  • Encryption = SSE, KMS, Client-Side (criptografa antes de enviar) e Customer Provided Keys
  • Server accesse logging = para outro bucket

Multi AZ

  • Ativado manualmente (você escolhe em qual AZ colocar)
    • EFS, ELB, ASG, Beanstalk (assign AZ)
    • RDS, ElastiCache
    • Aurora
      • Dados são automaticamente multi-az
      • Habilitar manualmente para o master DB em si
    • ElasticSearch: multi master
    • Jenkins (self deployed): multi master
  • Multi-az implícito
    • S3 (menos One-Zone IA)
    • DynamoDB
    • Todos os serviços
  • EBS
    • Vinculado a uma única AZ
    • "Gambiarra" pra multi-az:
    • ASG com 1 min/max/desired
    • Lifecycle hook para Terminate: criar um snapshot do EBS
    • Lifecycle hook para start: copiar o snapshot, criar um EBS e atachar na instância
    • PIOPS: Precisa fazer o pre-warm do disco lendo o volume inteiro uma vez

Multi-region

  • DynamoDB Global Tables (ativado pela Streams)
  • AWS Config Aggregators (multi region & multi account)
  • RDS = Cross Region Read Read Replicas (Usado p/ DR também)
  • Aurora Global DB = Master em uma região, read e DR em outra
  • EBS = Snapshots, AMIs, e RDS snapshots copiados p/ outras regiões
  • VPC Peering = tráfego privado entre regiões
  • Route53 = Global network
  • S3 = Cross Region Replication
  • CloudFront
  • Lambda@Edge = Lambda nos endpoints do Cloudfront -- Usado para A/B testing também

Arquiteturas

  • Multi Region c/ R53
    • ALB -> ASG -> EC2
    • 2 ALBs, 1 em cada região
    • Health check c/ failover de DNS automático
      • Integrado com CloudWatch Metrics
      • Notificações sobre healthcheck falhando via SNS
    • HC monitoram um endpoint (app, servidor, outro recurso)
    • HC monitora outro health check
    • HC monitora um alarme do CloudWatch

StackSets

  • Templates CloudFormation consistentes, multi-regiões
  • Conta administrador cria StackSets
  • Contas "trusted" criam, atualizam, deletam recursos dos StackSets
  • Atualização é feita em todas as stacks
  • Definir máximas ações simultâneas e tolerância a falhas (números ou %)
  • Configuração
    • Criar uma AdministrationRole, que vai liberar sts:AssumeRole na role AWSCloudFormationStackSetAdministrationRole
    • Criar uma ExecutionRole, que vai ter AdministratorAccess na conta e vai poder fazer o AssumeRole para a AdministrationRole
    • Habilitar AWS Config
  • Deployment
    • Escolher accounts ou OUs, passando o número da conta
    • Escolher regiões para fazer deploy
  • Editar (adicionar novas stacks)

CodePipeline - Multi-region

  • CodePipeline copia artefato da pipeline para outras regiões
  • E aciona o CodeDeploy em outras regiões
  • No CodePipeline, na ação do CodeDeploy dá pra escolher outras regiões

Disaster Recovery

  • Desastre = evento que impacta negativamente a continuidade ou receita do negócio
  • Disaster Recovery (DR) = preparar e se recuperar de um desastre
  • Métodos
    • On-premise -> On-premise (tradicional, bem caro)
    • On-premise -> AWS ("Hybrid recovery")
    • Region A -> Region B
  • RPO = basicamente, qual a frequência do seu backup
    • Tempo de perda de dados
  • RTO = downtime

Estratégias de DR

  • Em ordem do maior RTO e menor custo para o maior
  • Backup & Restore
    • RPO alto
    • Storage Gateway -> S3
    • Snowball -> Glacier
    • Snapshots agendados
  • Pilot Light
    • Versão pequena da aplicação sempre roda na cloud
    • Similar ao backup & restore, mas os sistemas crítios já estão de pé
    • Data replication, EC2s desligadas
  • Warm Standby
    • Sistema inteiro de pé, mas com um tamanho mínimo
      • Instâncias lendo do banco master
      • Replicação de dados para um banco slave
    • No desastre, escala para a carga de produção
      • Failover para o DB slave
  • Hot Site / Multi Site
    • RTO muito baixo (minutos ou segundos), mas é bem caro
    • Sistema a nível de produção rodando na AWS e on-premises
    • On premises ou full AWS
    • Aurora global ou read replica
  • Dicas gerais
    • Snapshots/backups automatizados
    • Enviar snapshots pro S3, lifecycle policy, cross region replication
    • Do on-premises p/ AWS = Snowball ou Storage Gateway
    • Route53 para cross region
    • MultiAZ, EFS, S3
    • Site to Site VPN como recuperação do Direct Connect
    • RDS Cross Region Replication, Aurora + Global DBs
    • Automação para DR
      • Elastic BeanStalk
      • CloudFormation
      • Recuperar / Rebootar instâncias se alarmes CloudWatch falharem
      • Lambda functions
    • Chaos engineering
  • DR Checklist
    • AMI copiada para outra região? Referência no Parameter Store (para usar no CFN)
    • StackSet funcionando e testado em outra região?
    • Qual o meu RTO e RPO? (Custos também)
    • Os health checks estão funcionando corretamente? Estão vinculados a um alarme?
    • Automatizar promoção do RDS Read Replica
    • Onde está o backup-dos dados? Qual RPO e RTO?
    • Backups & multi-region
      • AWS Backup com EFS -- frequência, retenção, etc -- serviço gerenciado
      • Route53 backup = ListResourceRecordSets, criar um script para importar para o R53 ou outro provider
      • EB = salvar configurações

On-Premise Strategies

  • Baixar AMI do Amazon Linux como uma VM (formato .iso)
  • VM Import / Export
    • Migrar versões existentes das VMs para o EC2
    • Criar estratégia de DR para o on-premises (entrada e saída)
  • Application Discovery Service
    • Mapear os servidores on-premise pra planejar uma migração
    • Pegar uso dos servidores, mapear dependências
    • Gerenciar migração com AWS Migration Hub
  • AWS DMS
    • Replicar On-prem => AWS, AWS => AWS, AWS => On-prem
    • Várias tecnologias
  • AWS Server Migration Service (SMS)
    • Replicação incremental de servidores para a AWS
    • On-going incremental replication

AWS Organizations

  • Serviço global
  • Gerenciar múltiplas contas AWS
  • Conta principal é a master, não dá pra mudar
  • Outras contas são members, podem ser parte de apenas 1 organização
  • Members podem mudar de uma Organization pra outra (migration)
    • Remover conta de uma organization
    • Mandar invite para a nova organization
    • Aceitar o invite
    • Migrar conta master
      • Remover todas as outras contas da org, deletar a org, invitar a master antiga para a nova
  • Billing consolidado, único método de pagamento
  • Descontos em volume para EC2, S3, etc
  • Service limits por conta
  • CloudTrail enviar para a conta S3 central
  • CloudWatch Logs para a conta de logging

Organizational Units

  • Grupos de contas
  • OU Sales | Retail | OU Finance ou OU Dev, Homolog, Prod ou Project-based
  • Nested OUs, herança
  • Service Control Policies (SCP)
    • Igual policy IAM
    • Whitelist ou blacklist IAM actions
    • A nível de OU ou conta
    • Não se aplica a service-linked roles ou à Master Account
    • Aplicada a todos os usuário e roles da conta, incluindo o root
    • Precisa ter um allow
    • Ex: Não pode usar EMR na conta prod, ou PCI compliance
    • Deny explícito > Allow

AWS - Multi Account

  • IAM Trust / STS
  • CodePipeline -> Cross account CodeDeploy
  • AWS Config (aggregators)
  • CloudWatch Events - Event Bus = multi-account events
  • CloudFormation - StackSets
  • Centralizar logs em uma conta de logging
    • Criar um CloudWatch LogDestination (via CLI) na outra conta
    • Criar um FireHose para receber e mandar para o S3
Raw
02-booya.md

Booyaa - Blog post series

https://booyaa.wtf/2019/aws-devops-pro-certification-intro/

Domain: SLDC automation

  • CI/CD, SCM, testes automatizados, build/artefatos seguros, estratégias de deploy/delivery

Serviços e produtos

  • CodeCommit - SCM com git
    • HA, durabilidade, escalável
    • Encryption at rest e in transit
    • Suporta PRs
  • CodeBuild - Parte de um CI, build de código e produção de artefatos
    • Escala automaticamente com requests
  • CodeDeploy - Parte de um CD, entrega
    • código, lambdas, web e config files, executáveis, pacotes, scripts, arquivos multimídia
    • escala de acordo com a infra, pode fazer deploy pra 1 instância ou 1000
  • CodePipeline - Esteira de entrega

Domain: Configuration Management and IaC

  • Estratégias de deployment
  • Segurança na automação de provisionamento de recursos
  • Lifecycle hooks
  • Gerenciamento de sistemas

Serviços e produtos

  • CloudFormation: linguagem de template para codificar infraestrutura
  • OpsWorks: IaC/Gerência de configuração com Chef e Puppet
  • Elastic Beanstalk: PaaS
  • Lambda: Serverless functions
  • ECS: Containers gerenciados
  • AWS Config: Auditoria de serviços AWS
    • Avaliar e auditar configuração de recursos AWS
    • Monitora configurações, permite comparar com valores desejados
    • Saída para SNS, CloudWatch Events, S3
  • AWS Managed Services: AWS gerenciando AWS
    • Serviço opera a AWS por você
    • AWS Landing Zone, modelo operacional
    • Automatiza atividades comuns de gerenciamento de infraestrutura
    • Forma segura de organizações grandes migrarem do on-prem para cloud-based, porém sem ter experiência pra fazer isso

Domain: Monitoring and Logging

  • Agregar, armazenar e analisar logs e métricas
  • Automatizar monitoramento e gerenciamento de eventos
  • Auditar, logar e monitorar OS, infras e aplicações
  • Determinar como implementar tagging e estratégias de metadados

Serviços e produtos

  • CloudWatch: Monitoramento dos recursos cloud e aplicações
  • X-Ray: APM, Análise e debug de aplicações. Similar ao Sentry
    • Integração com EC2, ECS, Lambda e EB
    • Java, NodeJS, .NET

Domain: Policy and Standards Automation

  • Reforçar padrões pra logging, métricas, monitoramento, testes e segurança
  • Otimizar custo com automação
  • Estratégias de governança

Serviços e produtos

  • Service Catalog: Catálogo de serviços que os usuários podem criar

    • "Esconder" a implementação dos usuários
    • Produtos = Stacks de aplicações criados pelos admins, que serão transformados em recursos AWS
    • Portfolios = Coleção de produtos
    • Usuários = Podem criar esses produtos sem precisarem acessar a AWS ou o console (via API)

  • Trusted Advisor: Aponta recursos que não estão nas melhores práticas da AWS

    • Otimização de custos (baixa utilização)
    • Performance: configuração que pode impactar na performance
    • Segurança: Aspectos de segurança ex MFA na conta root
    • Tolerância a falhas: Reporta recursos que não são tolerantes a falha
    • Limites de serviço: Recursos que estão perto de chegar nos limites
    • Plano de suporte básico: 7 checks base (6 de segurança e os de service limit)
    • Plano de suporte business/enterprise: Todos os checks e relatórios

  • Systems Manager: Serviço de gerenciamento de infraestrutura

    • Inventário: instâncias e software instalados nelas
    • Compliance de configuração: compliance de patches e configuração, reporta o que estiver divergente
    • Automação: Automatiza tarefas repetitivas e relatórios
    • Run command: executa comandos em um/várias instância(s) - Estilo "SSH"
    • Patch Manager: Aplica patches e updates imediatamente ou via janela de manutenção
    • Maintenance windows: Agendar manutenções e indisponibilidade
    • Distributor: mecanismo de distribuição de pacotes
    • State manager: armazena políticas que podem ser reaplicadas em recursos quando a configuração estiver divergente
    • Parameter store: Segredos e variáveis de configuração

  • Organizations

    • Organizar o ambiente baseado na hierarquia ou papéis funcionais (segurança, complience, dev, financeiro, etc)

  • Secrets Manager: Armazenamento de chaves e segredos com criptografia

    • Encryption at rest usando KMS
    • Credenciais de banco, senhas e API keys
    • Rotação de senhas agendada
    • Integração com credenciais do RDS (?, validar)

  • Macie: identificar, classificar e proteger dados sensiveis

    • Machine Learning
    • Reconhece PII ou propriedade intelectual
    • Apenas para S3 por enquanto
    • Healthcare e governo, dados de clientes

  • ACM: centraliza o gerenciamento de certificados TLS/SSL

    • Boa integração com recursos AWS
    • Consegue definir uma CA privada para ser usada internamente

Domain: Incident and Event Response

  • Troubleshooting e restaurar operação
  • Automatizar gerenciamento de eventos e alertas
  • Healing automatizado
  • Ações automatizadas acionadas por eventos

Serviços e produtos

  • GuardDuty: monitorar comportamento malicioso ou não autorizado
    • Reconhecer: scanning de portas, falhas de login, atividade de API estranha e acesso de IP malicioso conhecido
    • Comprometimento de instância: malware, DoS outbound, volume alto de tráfego, atividade de um IP conhecido, etc
    • Comprometimento de conta: ttentativa de desabilitar logging do CloudTrail, lançamento de instâncias ou infraestruturas estranhos (ex. gpu para crypto mining)
    • Retenção de dados é de 90 dias
    • Workflow para reação/respostas (ex. CloudWatch Events + Lambda)
  • Inspector: serviço automatizado de assessment de segurança
    • Focado em EC2
    • Verifica acesso de rede não desejado e vulnerabilidades em EC2
    • Verifica CVEs e versões de software com vulnerabilidades
  • Kinesis: Streaming gerenciado

Domain: HA, Fault Tolerance and DR

  • Uso apropriado de Multi-AZ vs multi-região
  • Implementar HA, escalabilidade e tolerância a falhas
  • Determinar os serviços corretos baseados na necessidade de negócio (ex. RTO/RPO, custo)
  • Design e automatização de estratégias de DR
  • Procurar pontos de falha em um deployment

Serviços e produtos

  • AWS SSO: Integração com AD
  • CloudFront: CDN
  • Route53: DNS
    • Failover routing: automatizar DR, altera o apontamento com base em health checks
    • Geolocation routing: rotear tráfego baseado na localização dos usuários
    • Geoproximity routing: rotear baseado na localização dos seus recursos, porém permite rotear para uma localização secundária. Também é bom pra tolerância a falhas
    • Multivalue answer: randomicamente escolher um entre até 8 registros, permite health check
    • weighted routing: permite rotear tráfego baseado em uma porcentagem
  • Auto Scaling:
    • Conceito de lifecycle hooks, pausar instância quando o ASG lança ou termina ela
  • RDS: DBMS relacioanl
  • Aurora: MySQL/Postgres gerenciado, mais performático
    • Melhor pra DR, failover pra até 15 read replicas
    • Continua funcionando mesmo se perder 2 cópias de dados para escrita, e 3 para leitura
  • DynamoDB: NoSQL, key-value pairs ou documents
Raw
03-simulados.md

Revisão dos simulados - questões que errei

WhizLabs - Practice Test I - 10/05

Domain Total Question Correct Incorrect Unattempted Marked as Review % erros % review
High Availability, Fault Tolerance, and Disaster Recovery 12 8 4 0 6 33.33% 50.00%
SDLC Automation 14 8 6 0 10 42.86% 71.43%
Incident and Event Response 8 6 2 0 4 25.00% 50.00%
Policies and Standards Automation 12 7 5 0 8 41.67% 66.67%
Configuration Management and Infrastructure as Code 23 18 5 0 13 21.74% 56.52%
Monitoring and Logging 11 10 1 0 7 9.09% 63.64%

Revisão das questões

  • Blue/Green deployment com EC2 = novo Load Balancer e ASG. Deploy, testes, quando estiver OK trocar o domínio no R53

  • Git clone funciona tanto pra https:// quanto pra ssh://. CodeCommit não permite HTTP (sem o S)

  • CodeBuild suporta as seguintes plataformas: Amazon Linux 2, Ubuntu 18.04, Windows Server 2016.

    • Dentro dessas plataformas você pode rodar várias imagens Docker

  • CodePipeline

    • Sources suportadas = CodeCommit, GitHub, BitBucket, S3 e ECR (usado em fluxo tipo: docker push - build - deploy)
    • Build stages suportadas = CodeBuild, Jenkins
    • Deploy stages suportadas = CloudFormation, CodeDeploy, Elastic Beanstalk, Service Catalog, ECS e S3

  • Route 53 - Weighted Round Robin = Weighted routing

  • API Gateway = Suporte nativo para Canary Deployment

  • Deployment Strategies

    • Blue/Green = 2 versões idênticas, sistema troca para o novo ambiente para todo o tráfego. Estudar whitepaper
    • Rolling Deployment = Divide o ambiente em batches e executa um batch por vez até atualizar tudo
    • Red/Black = Mesmo conceito do blue/green. Usado pela Netflix, Istio, etc
    • A/B Testing = 2 versões de uma aplicação/feature são testadas com os mesmos usuários pra decidir qual é o melhor
    • Canary = Subset de usuários/tráfego é roteado para a nova versão

  • Análise de logs = ElasticSearch é mais recomendado

  • Análise em tempo real dos logs = Kinesis

  • ElasticSearch Domain = Sinônimo de Cluster

  • Trusted Advisor Cost Optimization não tem notificações para o SNS por padrão

  • AWS S3 Analytics: Gera relatório sobre a utilização dos recursos do S3. Docs

  • AWS Config não ajuda com redução de custo, apenas com compliance das políticas de redução

  • HDD (st1) é mais barato que SSD (gp2)

  • Right-sizing solution = subir uma EC2 com um script, rodar um Redshift pra fazer a análise

  • OpsWorks tem feature de auto f (se o agent não conseguir se comunicar, substitui a instância)

  • ElasticBeanstalk não tem auto healing nativo. O que tem é o health check do load balancer e o ASG

  • CloudFront não consegue fazer cache das requisições do DynamoDB

  • Estudar

    • CodePipeline (fazer PoC com S3, EC2, Lambda e ECS)
    • Elastic BeanStalk
    • Blue/Green Deployments
No Domain Total Question Correct Incorrect Unattempted Marked as Review % erros % review
1 High Availability, Fault Tolerance, and Disaster Recovery 15 10 5 0 11 33.33% 73.33%
ect Unattempted Marked as Review % erros % review
2 Incident and Event Response 7 6 1 0 5 14.29% 71.43%
3 Configuration Management and Infrastructure as Code 25 17 8 0 14 32.00% 56.00%
4 SDLC Automation 8 6 2 0 6 25.00% 75.00%
5 Monitoring and Logging 15 9 6 0 12 40.00% 80.00%
6 Policies and Standards Automation 10 10 0 0 6 0.00% 60.00%

Revisão das questões

  • RDS Multi Az = Synchronous Replication
  • RDS Read Replica = Asynchronous Replication
  • EMR = Processar large data sets
  • Mensagens no SQS maiores que 256 KB = Java Extended Client Library, armazenar o body no S3
  • Amazon Macie data sources = S3 e CloudTrail
  • QuickSight = BI com Machine Learning para analisar dados
    • Data Sources válidos = Athena, Aurora, Redshift (+ Spectrum), S3 (+ Analytics), Spark 2.0+, AWS IoT Analytics, MariaDB 10.0+, SQL Server 2012+, MySQL 5.1+, PostgreSQL 9.3.1+, Presto 0.167+, Snowflake, Teradata 14.0+
    • Arquivos data source válidos = CSV/TSV, ELF/CLF (log format), JSON, XLSX
      • Aceita compressão zip ou gzip
  • Criar AMI = mais rápido que user data
  • AWS Health Dashboard = Não tem notificação por padrão, tem que usar o CW events
  • CloudWatch Logs Streaming = ElasticSearch e Lambda
  • AWS ASG Notifications = Suporte nativo, envia para SNS nos seguintes status de instancias:
    • Launch, Terminate, Fail to Launch, Fail to Terminate
  • AWS ASG Lifecycle Hook Notifications = Possível de implementar, para os serviços
    • CloudWatch Events (p/ mandar pra Lambda)
    • SNS
    • SQS
  • DynamoDB Keys
    • Hash key/Partition Key/Primary Key = coluna que vai ter mais valores distintos
    • Range key/Sort key = Usado pra ordenar, otimizado para queries como begins_with, between, >, <, etc. Acredito que seja similar ao índice no SQL
  • Firehose = Carregar dados de streaming na AWS. Capturar, transformar e carregar dados em:
    • Kinesis Analytics, S3, Redshift, ElasticSearch
  • Linguagem do Redshift = SQL com funcionalidades adicionais
  • ASG & Spots = Possível de configurar usando Launch Template
    • Launch Template = Configuração nova, lançar uma combinação de tipos de instância e opções de compra. Podem ser atualizados
  • MTU = Maximum Transmission Unit = Tamanho máximo do pacote que pode passar pra conexão
    • Quanto maior o MTU, mais dados podem ser enviados em um único pacote
    • Em instâncias em cluster placement group, é ideal usar Jumpbo Frames pois eles permitem um MTU de 9001
  • Dynamo GSI = Pode ser configurada depois de criar a tabela, o LSI não
  • GSI = Índice com hash e range key, podem ser diferentes dos usados na tabela. O índice pode ser distribuído em todos os dados da tabela, sobre todas as partições (por isso que é chamado de "Global")
    • Você precisa pagar pelo RCU e WCU
  • LSI = Índice com o mesmo hash key da tabela, mas um range key diferente. Permitidos até 5. "Local" porque cada partição de um LSI tem o escopo de uma partição da tabela com a mesma hash key
  • RDS Automated Snapshots não podem ser compartilhadas. Tem que copiar na mão antes
  • DynamoDB Global Tables = Multi-region multi-master db, sem precisar configurar replicação.
  • AWS Cognito = Login com Facebook = Permissão pra acessar recursos AWS como S3
  • CloudFormation - DB Replace = Deleta todos os snapshots automatizados
  • AWS AD Connector = Directory Gateway pra conectar com AD on premises
  • AWS Simple AD = Serviço de AD da AWS
  • CFN Custom Resource = Passar Service Token, pra onde o CFN vai enviar as requisições CRUD
    • SNS
    • Lambda
  • CloudWatch - gráficos de 1 minuto ficam disponíveis por 15 dias
  • EB CLI = eb create
  • Arquivos na pasta .ebextensions = Extensão .config
  • Lambda 1000 execuções concorrentes
  • No EB é possível configurar pra ignorar o Health Check ao fazer deploy
    • Também dá pra baixar othreshold de Healthy (ex. pra que instâncias degraded sejam consideradas healthy)
    • E o timeout do comando de deploy também
  • Aurora Global Database = MySQL e PosgreSQL, read only, replicado em menos de 1s
    • DR = Promover secundário para read e write
    • Cobrança de IO replicado entre a região
  • Instalar AWS Inspector agent via console = Precisa ter SSM cnfigurado
  • CloudWatch Event Bus = Enviar eventos entre contas
    • Não precisam ser da mesma organization
    • Master account precisa permitir receber os eventos
    • Pode dar permissão pra Everybody (*)
    • Região onde as permissões são adicioandas deve ser a mesma região de onde é criada a regra pra enviar os eventos

WhizLabs - SLDC Domain Test - 20/05

Revisão das questões

  • CodeCommit = Encriptado at rest e on transit automático, por padrão
  • RDS no Elastic BeanStalk não é recomendado para ambiente de produção, pois o lifecycle do banco fica ligado ao lc da aplicação
  • DataPipeline Start/End time: hora que a pipeline vai ser encerrada, não está relacionado aos horários de execução
    • Você escolhe uma periodicidade (ex. 1 dia, 5 minutos, etc)
    • Escolhe a data de início (manual, ou agendado)
    • Escolhe a data de término (nunca, depois de X execuções ou agendado)
  • EB com multidocker = arquivo dockerrun.aws.json v2
  • Todas as chamadas do CloudFormation são logadas no CloudTrail
  • ECS = Apenas EC2 instances, on premises não

WhizLabs - Practice Test III - 27/05

No Domain Total Question Correct Incorrect Unattempted Marked as Review % erros % review
1 Configuration Management and Infrastructure as Code 22 16 6 0 16 27.27% 72.73%
2 High Availability, Fault Tolerance, and Disaster Recovery 17 12 5 0 6 29.41% 35.29%
3 Policies and Standards Automation 10 9 1 0 6 10.00% 60.00%
4 SDLC Automation 22 16 6 0 12 27.27% 54.55%
5 Incident and Event Response 6 3 3 0 5 50.00% 83.33%
6 Monitoring and Logging 3 1 2 0 2 66.67% 66.67%

Revisão das questões

  • DynamoDB Streams
    • Mostra os dados como eram antes e depois que foram modificados
    • Encriptado
    • Acionado quando cria, edita ou deleta
    • Log apenas por 24 horas
  • Elastic BeanStalk
    • Prioridade das alterações = Console/CLI/SDK > ebextensions > default
    • Ordem de instalação dos pacotes não é garantida
    • Package managers suportados: yum, rubygems, python, rpm
    • É possível version pinning
  • CloudWatch Events
    • EC2 CreateSnapshot API Call como target
  • AWS Step Functions
    • Parecido com o SWF, mas possui o conceito de State Machine
    • Deve ser usado no lugar do SWF, a não ser que você precise de intervenção externa ou processos filhos que retornem para um pai.
    • Workflow driven pipeline actions
  • AutoScaling Group
    • Lifecycle hook
      • Estado Wait, ASG vai esperar por até 1 hora
      • É possível mandar um "heartbeat" pra resetar o timeout de 1 hora
      • Quando finalizar, enviar um sinal pra finalizar o launch da instância
  • CodePipeline
    • Artefatos
      • Default Location = bucket codfepipeline-{region}-algumacoisa, mesma região e conta da pipeline
      • Custom location = bucket existente, mesma região e conta da pipeline tbm
  • CloudFormation
    • DeletionPolicy: Preservar ou (em alguns casos) fazer backup de um recurso
      • Retain - não será deletado
      • Snapshot - snapshot será feita antes de remover
      • Delete - irá excluir
      • Snapshot por padrão em AWS::RDS::DBCluster e AWS::RDS::DBInstances que não especificam o DBClusterIdentifier

Udemy - Stephane Mareek - 15/06

Domain # questões % acertos % erros # acertos # erros
Domain 3: Monitoring and Logging 11 64% 36% 7 4
Domain 2: Configuration Management & Infrastructure as Code 16 63% 38% 10 6
Domain 6: High Availability, Fault Tolerance, & DR 10 80% 20% 8 2
Domain 5: Incident and Event Response 13 62% 38% 8 5
Domain 4: Policies and Standards Automation 9 56% 44% 5 4
Domain 1: SDLC Automation 16 75% 25% 12 4
  • Step Functions é desejável para workflows complexos, que podem envolver re-tentativas, e que precisam de uma trilha de auditoria para cada workflow
  • Licença baseada no número de CPU Sockets = Dedicated Hosts para ter acesso
  • CodeDeploy não tem "aprovação manual" ou forma de sinalizar pra ele finalizar a execução
  • CodeDeploy BeforeAllowTraffic = hook utilizado antes do CodeDeploy 'virar' o tráfego pra nova versão
  • Analisar logs serverless e com baixo custo = Athena
  • EMR é "on-demand" e custo alto, não é serverless
  • OpsWorks = Auto-healing, mas não manda notificações via SNS
    • Notificações = CloudWatch Event - aws.opsworks - initiated-by = auto-healing
  • Jenkins + CodeBuild Plugin = Elastic, "serverless"
  • Elastic BeanStalk Commands
    • Commands = Rodam no começo do deploy
    • Container Commands = Rodam após a configuração e entrega do código, mas antes da atualização da versão (mover a pasta com o código/binário)
      • Apenas esse tem suporte para o leader_only
  • SSM Automation = Criar AMI de forma repetível / reproduzível
  • Autoscaling hooks = default timeout de 1 hora se não mandar extender, não é muito legal pra troubleshooting
    • Standby = melhor alternativa
    • Termination Protection não vai impedir o ASG de terminar a instância
  • Blue/green com problema de DNS - Solução = usar 1 ALB e 2 Target Groups
  • CodeCommit - Evitar commit na master = IAM Policy
  • CodeDeploy - EC2 Canary = Criar um Deployment Group pequeno de instâncias e fazer o deploy nele
  • CodeDeploy - ValidateService = Antes de começar a receber tráfego do ELB
  • S3 - Forçar SSL = Criar policy Deny aws:SecureTransport = false
  • SSE-KMS = throttling com muitas requisições (>10.000) por segundo. Usar SSE-S3 no lugar
  • EFS - Cross Region Replication - Sem VPC Peering
    • Cluster EC2 + autoscaling na região A
    • Escala baseada em lag nas leituras
    • Replicar os dados no S3 na região B
    • Criar outro cluster de replicação na região B
    • Lê do S3 e copia para um EFS standby
    • Replicar file ACL se necessário
    • OU serviço DataSync
  • Dynamo API call invocations (independente do resultado) = CloudTrail
  • Dynamo API call result = Streams
  • CloudWatch Logs - Cross account = Kinesis Streams
  • SSM Automation = Aprovação manual
  • Trusted Advisor + CloudWatch Events = reação automatizada (ex. baixa utilização)
  • AWS Config + SNS = Todas as notificações, incluindo mudança de configuração
    • Notificações apenas sobre uma regra = CloudWatch Events
  • Read requests shared = Hot partition = DAX
  • DAX = ElastiCache para DynamoDB. Cache para reduzir custos
  • CloudFormation não detecta que o código da lambda mudou a não ser que o valor do path do objeto mude
    • Soluções: Object Versioning, Mudar nome do arquivo e Mudar nome do bucket
  • Verificar integridade dos logs do CloudTrail = validate-logs API call
  • CodeDeploy não é integrado com os health checks do ALB -- Usar ValidateService no appspec.yml
  • SSM Inventory = Pega os programas que estão instalados também
  • CloudFormation Nested Stacks = Componente reusável em várias stacks (tipo módulos)
  • Boa prática CloudFormation = Templates individuais, integração através de outputs
  • CodeBuild = Variável CODEBUILD_SOURCE_VERSION contém o nome da branch atual
  • CodeDeploy - In-place updates = Todas de uma vez só
  • CodeCommit "hooks" - CloudWatch Events
  • CodeDeploy HANDLE_PROCS=true = Suspende eventos de scaling durante o deploy
  • SSM On-premises = Activation code & id, passados pro SSM Agent na hora da ativação
    • Precisa de uma service role permitindo assumir o SSM service
    • Dá pra usar o mesmo código pra mais de uma instância

AWS - Practice Test - 25/06

1.0  SDLC Automation: 75% 2.0  Configuration Management and Infrastructure as Code: 66% 3.0  Monitoring and Logging: 100% 4.0  Policies and Standards Automation: 66% 5.0  Incident and Event Response: 50% 6.0  High Availability, Fault Tolerance, and Disaster Recovery : 100%

Udemy - Tutorials Dojo - 27/06

  • 78%
  • SLDC Automation: 26% de erro - 6/23 perguntas
  • Incident & Event Response: 67% de erro - 2/3 perguntas
  • CM & IaC: 9% de erro - 2/22 perguntas
  • Policies & Std Autom8n: 22% de erro - 2/9 perguntas
  • HA, FT & DR: 25% de erro, 1/4 perguntas
  • Monitoring & logging: 21% de erro, 3/14 perguntas

Domains para estudar:

  • SLDC
  • Incident & Evt Response
  • Monitoring & Logging

Pontos fracos que percebi

  • CodeDeploy / appspec.yml / Melhores práticas
  • Lambda @ Edge vs API Gateway Edge Endpoints
  • EB deployments - Immutable? Blue/Green c/ ASG?
  • 5xx e 4xx codes
  • RDS auto failover c/ health notifications
  • S3 logging
  • Aurora & HA (Multi-master, Global DBs)

Explicação das que errei/fiquei com dúvida

  • CodeDeploy - Test Traffic
    • Definir teste na Lambda Function
    • CodeDeploy usa um LB configurado com 2 TGs, um de tráfego de produção e outro com tráfego de testes
    • EC2/On premises = Teste feito via scripts
    • ECS = Teste feito via Lambda
    • AfterAllowTestTraffic
      • Chamar Lambda ou script pra validar usando o tráfego de testes
    • BeforeAllowTraffic = Validação já foi feita com sucesso, esse hook é só pra fazer algumas ações adicionais antes de permitir o tráfego de produção
    • AfterInstall = A nova versão da task ainda não está nem atachada no Load Balancer, não daria pra fazer validação aqui
  • CodeDeploy - Retenção de arquivos
    • Por padrão, o CodeDeploy remove todos os arquivos instalados no último deployment
    • Arquivos que não fazem parte do deploy = Você escolhe o que fazer
      • Fail the deployment = Dá ero e o deploy é abortado
      • Overwrite the content = Arquivos são substituídos pelos definidos na nova versão
      • Retain the content = Mantém os arquivos que não faziam parte do último deployment, e agora eles passam a fazer parte deste.
  • CodeCommit to SNS = Tem que ser na mesma região
  • Acesso ao S3 apenas pelo CloudFront
    • Signed URLs ou Cookies
    • Criar um usuário do CloudFront chamado Origin Access Identity (OAI)
    • OAI acessa os arquivos e serve-os para os usuários
  • CNAME não pode ser usado no domínio raíz (Zone apex)
  • EB - Produção = Banco desacoplado
  • DynamoDB Global Tables = Você manualmente especifica e cria as tableas de réplicas nas regiões que você quer
    • Precisa habilitar DynamoDB Streams pra funcionar
  • DynamoDB mais escalável que Aurora
  • AWS SSM Patch Groups = Por tags na EC2
    • Patch Group = DEV
  • Instrumentação de ECS com X-Ray
    • Docker image com X-Ray Daemon
    • Daemon escuta por tráfego UDP na porta 2000
  • EB - Immutable update = Novo ASG
Raw
04-hands-on.md

Anotações - Hands-on e FAQs

SSM

  • Ativar managed instance = Instalar o SSM Agent e adicionar um Instance Profile c/ permissões para o SSM
  • Document = Configuration as Code
    • JSON ou YAML
    • Run Command
    • State Manager
    • Automation
  • AppConfig = Validar e aplicar configurações em aplicações EC2, containers, lambdas, mobile apps ou devices IoT
  • Automation = Roll out incremental e parar quando der erro
  • Run Command = controlar taxa de execução, com batches e thresholds de erro

CodeCommit

  • Clone do repo via HTTPS, SSH
  • IAM ou Credentials Manager para acesso federado ou tokens temporários
  • Gerar credenciais para https (usuário e senha)
  • Subir chave pública para SSH
  • Notificações em eventos para o SNS
    • On commit, on PR, approvals, PR updates, branches

FAQ

  • Comparação com S3 Versioning = CodeCommit permite features do Git (branching, diff, etc), vversioning não rastreia multiplos arquivos
  • Subversion e Perforce = apenas se migrar para Git
  • Suporte para git submodules
  • Tamanho máximo do arquivo de 2GB
  • 1.000 repositórios por conta, possível de aumentar
  • Suporte para webhook = SNS Notification para endpoint HTTP
  • Encryption at rest automática
  • Acesso cross account é possível, usando IAM Assume Role e STS
  • Pricing
    • $1 por usuário ativo por mês
    • Cada usuário = 10GB/mês e 2.000 requisições do Git /mês
    • Storage adicional = $0.06/gb/mês
    • Requests adicionais = $0.001 / request

CodeGuru

  • Em preview, provavelmente não caia na prova
  • Recomendações de performance, eficiência e qualidade em aplicações Java
  • Machine Learning
  • Profiler
    • Visualiza a performance da aplicação, mostrando o que leva mais tempo e CPU, recomendações
  • Reviewer
    • Avalia o código contra as melhores práticas nos repos open-source populares e a base da AWS

CodeStar

  • Facilita o desenvolvimento e entrega de aplicações com uma interface unificada
  • Gerenciar continuous delivery
  • Gerenciar permissões de acesso para owners, contribuidores e viewers
  • Dashboard p gerenciamento, com issue tracking by JIRA
  • Só paga pelos recursos da aWS
  • Suporte para integração com GitHub
  • Cria repo, codebuild, codedeploy, etc
  • Totalmente demais

CloudWatch

  • Suporta qualquer OS suportado pelo EC2
  • Permissões do IAM não podem ser definidas a nível de métricas ou dimensões
  • CloudWatch Logs Agent = Amazon Linux, Ubuntu, CentOS, RHEL e Windows
  • Anomaly Detection = machine learning, analisa sistemas e aplicações, determina um normal e mostra anomalias
    • Alarmes que se auto-ajustam
  • Custom Metric > Logs = Quando o dado não é produzido em formato de logs
  • CW Logs
    • Agent envia a cada 5 segundos por padrão
    • Logs text based ou json
    • Metric filters não suporta regex
  • CW Alarms - Ações
    • AutoScaling ou ECS
    • EC2 - Stop, Terminate, Reboot instance
    • SNS
    • Lambda (através do SNS)
Raw
05-whitepapers.md

Blue/Green Deployments on AWS

  • Enviar uma porção de tráfego de produção para o ambiente Green = Canary Analysis ou Canary Testing

Técnicas para fazer blue/green deployment

Atualizar DNS com Route53

  • Se aplica para:
    • Instâncias com IP público ou EIP
    • Grupos de instâncias atrás de um load balancer
    • Instâncias em um ASG com um ELB
    • Serviços no ECS com um ELB
    • Elastic Beanstalk web tiers
    • Outras configurações que expõem um IP ou DNS
  • Load balancers podem ser pré-aquecidos com uma solicitação pro suporte
    • ELB pode precisar de um tempo pra escalar, assim como as instâncias
  • Rollback = Por causa do TTL, algumas sessões podem estar vinculadas ao ambiente problemático

Atualizar ASG por trás do ELB

Página 14

Raw
06-whizlabs.md

WhizLabs course

Domain 1: SLDC Automation

  • DevOps = Melhorar colaboração, comunicação e integração entre Dev e Ops
  • Automação
    • Infra = código - controle de versão + SLDC
    • Testing = automatizado, unit, integration, stress, pentests
    • Deployment = Repeatability & consistency entre a aplicação -- 0 downtime
    • Monitoring = Know your application
    • Security = User management, separation of duties, automated security tests
  • Continuous Integration (CI)
    • CI = Prática de merge regular em um repositório central, onde builds e testes automatizados rodam
    • Entregar software mais rápido, melhorar qualidade e reduzir bugs
    • Jenkins = Uma das principais ferramentas de CI
  • Continuous Delivery (CD) = Mudanças são construídas, testadas e preparadas para uma release em produção
  • Continuous Deployment = Deployment em produção automatizado
  • DevOps = Ciclo completo, integração com os times de operação para pipelines de infra

Deployment Strategies

  • In-place deployment = Substituir a versão da aplicação nas instâncias
    • Impacto = Downtime
    • Rollback caro
    • Não é ideal para produção
  • Rolling deployment = Criar batches de deployments (grupos)
    • Se o grupo falhar, será feito rollback no grupo
    • Impacto = Um grupo sem funcionar
  • Rolling with additional batch (Elastic BeanStalk)
    • Rolling + instâncias adicionais
    • Aumenta o desired de instâncias, faz o deploy nelas e registra elas no LB. Depois, faz o deploy no resto das instâncias e se não der nenhum problema diminui o desired de volta
    • Impacto mínimo se a falha for pega no primeiro batch
  • Immutable = Estilo o da Celk
    • Sobe o desired do ASG, espera as instâncias subirem e passarem o healthcheck, diminui o desired matando as instâncias antigas
    • Se o health check falhar, rollback é rápido
  • Blue/Green = Sobe um ambiente "adicional", muda o DNS depois que subir
    • Aparece bastante na prova
    • Trocar rapidamente pro ambiente antigo em caso de rollback
    • Permite validação no ambiente novo antes de ir live
    • aka A/B deployment ou Red/Black deployment
  • Canary Deployment = X% do tráfego é redirecionado para o ambiente novo
    • AutoScaling pode adicionar as instâncias conforme o tráfego aumenta

CodeCommit

  • Source Control gerenciado e escalável
  • repositórios git privados => importante, foi pensado assim de início
  • Fluxo: CodeCommit -> CodePipeline -> CodeBuild -> CodeDeploy
  • Feature Branches
    • Nova funcionalidade, vai viver pela duração daquela feature e depois será mergeada em dev/master
    • Vida curta
    • Manter versão paralela do código da aplicação, isolamento

CodePipeline

  • Automação de CD - Build (CodeBuild, Jenkins) -> Test -> [Manual approval (SNS)] -> Deploy
  • Stages = Conjunto de ações
    • Integradas via transição
    • Actions = Source, Build, Test, Deploy, Approval, Invoke (Lambda)
  • GitHub = Usar Webhook mais rápido e recomendado. Alternativa é o CodePipeline fazer polling

CodePipeline Stages X Providers

source build test deploy approval invoke
S3 codeBuild codeBuild CloudFormation SNS Lambda
CodeCommit Jenkins DeviceFarm CodeDeploy
GitHub TeamCity BlazeMeter ECS
CloudBees Ghost Inspector Elastic BeanStalk
Solano CI Runscope OpsWorks
XebiaLabs

Comparison of Deployment Options

  • OpsWorks e CloudFormation Stacks suportam Route53 Weighted Policy
  • OpsWorks = Custo da "segunda" stack para Canary ou Blue/Green pode ser meio caro
  • TTL do DNS deve ser levado em consideração
  • EB - funcionalidade Swap Url
    • Migrar DNS de um ELB para outro
    • Não dá pra usar uma policy como weighted
  • Blue/Green pode ser feito com ASG também
    • Tráfego pro novo ASG será enviado de acordo com a routing policy no ALB
  • Blue/Green com nova alunch configuration, no mesmo ASG (caso da Celk)
  • Database Schema Changes devem estar fora do escopo do Blue/Green
    • Fluxo: Adições do schema -> Deploy -> Deleções do schema
  • Considerações de arquitetura podem afetar a escolha do modelo de deployment
    • Arquitetura da aplicação = Dependências, microserviços fracamente acoplados ou monolito
    • Organizacional = Agilidade e num. de iterações
    • Risco e complexidade = Impacto de deployments falhados, considerações de rollback
    • Time = Expertise do time de operações
    • Processo = Teste/QA, capacidade de rollback
    • Custo = Blue/Green é mais caro pois sobe 2 ambientes por um período de tempo
  • Considerações sobre a forma como o deployment é realizado:
    • Atualizar o DNS com Route53
      • Baixo nível de problemas e performance
      • Médio nível de problemas com pessoas, processos e falha de infra, depende do framework de automação
      • Alto nível de problemas com rollback, devido às complexidades com TTL do DNS
      • Custo é baixo pois pode ser otimizado via Auto Scaling
    • Trocar o ASG por trás do ELB
      • Gerência de divisão de tráfego é menos granular, o Load Balancer já está "aquecido"
      • Falhas de infra podem ser mitigadas com AutoScaling Healthchecks
      • Não tem complexidades com TTL de DNS
    • Atualizar Launch Configurations
      • Complexidade para detectar problemas nas instâncias novas
      • Divisão de tráfego é menos granular ainda
      • Custo é um pouco mais alto, não tem como ser otimizado via ASG
    • EB Swap URL
      • Não é possível fazer análise canary com tráfego de produção
      • Full cutover, não dá pra escalar do antigo para o novo
      • Problemas de TTL no DNS
    • OpsWorks clone stack
      • Análise canary facilitada, tráfego gradual
      • Problemas com TTL de DNS
      • Custo alto, stack duplicada

Domain 2: Configuration Management and Infrastructure as Code

OpsWorks Stacks

  • Mais difícil de usar do que o Elastic Beanstalk
  • Dá menos controle na infraestrutura que o CloudFormation
  • Hybrid / On Prem (Linux)
  • Automação para escala
  • Integra c/ CloudFormation e oturos serviços
  • Stack = coleção da infraestrutura
  • Layer = Agrupamento de instâncias similares
    • Load Balancer Layer
    • Application Server Layer
    • Database Layer
  • Tipos de instâncias suportadas
    • Windows Server - 2012 R2 & SQL Server - Chef 12.2
    • Linux - Amazon Linux, Ubuntu, CentOS 7, RHEL 7, AMI personalizada - Chef 12, 11.10
      • EC2 ou On-Premises
  • OpsWorks é Global
  • Auto Healing = Agent comunica com a AWS, se não acontecer a instância vai ser marcada será reiniciada para tentar corrigir
  • É possível aplicar permissões específicas pros usuários
    • Diferente das permissões do IAM
    • Dá pra liberar SSH/RDP, sudo/admin, apenas ver/deployar/gerenciar, etc
  • Shortname = obrigatório

Lifecycle Events

  • Setup = Após o boot da instância. Instância é considerada offline
    • Receitas para instalar dependências do OS
  • Configure = Acionado para todas as instâncias na stack, quando
    • Uma instância entra ou sai do estado online
    • EIP é vinculado / removido
    • ELB é adicionado ou removido de uma layer
  • Deploy = Custom deployment da aplicação - do repositório às instâncias da layer
  • Undeploy = Descomissiona a aplicação, limpeza
  • Shutdown = Limpeza (desligar serviços, remover volumes, etc)

Auto Healing

  • Heartbeat
  • Se não tiver comunicação por 300 segundos, instância é marcada como falhada e desligada
    • Instance store backed EC2 - lança uma nova pra substituir
    • EBS backed EC2, reinicia a mesma instância
  • Configure vai ser acionado em todas as instâncias quando ela ficar online

Elastic Load Balancer

  • Deve ser criado fora do OpsWorks
  • Atachado a 1 layer e apenas 1. 1 ELB por stack
  • Instâncias registradas no ELB quando online, deregistrada quando offline
  • Classic Load Balancer deve ser usado
    • Da pra colocar uma receita pra instância se auto-atachar no ALB ou NLB
  • Se o ELB já tem instâncias, elas serão removidas quando atachar no Opsworks

Service Layers

  • Integrar com RDS ou ECS (Linux)
  • Criados fora do OpsWorks (Console, CLI ou CloudFormation)
  • Criar uma service layer e associar com a stack
  • RDS requer security groups adicionados à application layer
  • Service Role do OpsWorks precisa receber permissão nesses serviços pra gerenciar eles

Custom Recipes

  • Acionadas automaticamente para qualquer evento (setup, configure, etc)
  • sintaxe = cookbookname::recipename
    • receita default = omitir o recipename -> cookbookname::default = cookbookname
  • Custom Recipes + Custom JSON e Data Bags
  • Instalar pacotes, configurar arquivos de ambiente (db), backup logs, unmount EFS

Applications

  • Bundle em repositórios (S3, HTTP, GIT)
  • Ou deployment
  • Artefato é um .zip ou .tar.gz
  • Distinguir versões pra permitir rollback (Git tags, S3 versioning)
  • Integração com CD como Jenkins
  • Custom JSON e env vars podem ser passadas no Deploy; receitas podem criar configurações específicas à versão

Domain 3: Monitoring and logging

CloudWatch

  • Logar, medir e monitorar serviços

CW Metrics

  • Namespaces = AWS/serviço
    • Quais serviços não estão no CloudWatch?
  • Métricas = Dos serviços ou custom
    • Possui timestamp de quando ocorreu
    • Por região (15 meses)
  • Dimensões
    • Filtrar e categorizar a métrica
      • EC2 instance Id, AMI
      • Rastrear um problema
  • Estatísticas agregadas criadas automaticamente pela AWS
    • Minimum, Maximum, Sum, SampleCount
    • Average = Sum / SampleCount
    • Percentile values
    • São agregadas em períodos de 1 ou 5 minutos, dependendo do que você está observando

Overview

  • Métricas são por região
  • System status checks = a nível de hypervisor, monitoram os sistemas da AWS necessários para manter a EC2 funcionando
    • Falha de rede
    • Falha de energia
    • Problemas de software no host
    • Problemas de hardware no host que impactam rede
  • Instance status checks = A nível de rede e OS
    • Problema com system status checks
    • Configuração de networking ou startup
    • Uso de memória excessivo
    • FS corrompido
    • Kernel incompatível
  • Basic monitoring = 5 minutos
  • EC2 Detailed Monitoring = 1 minuto, mais caro

CLI

  • aws cloudwatch list-metrics --namespace AWS/EC2 [--metric-name CPUUtilization] [--dimensions Name=InstanceId,Value=i-0619ar9q0321a]
  • get-metric-statistics = filtrar por um nome da métrica em um namespace, estatística, tempo inicial e final, e periodo
  • get-metric-data = obter os datapoints para arquivar no S3 para uso futuro

Custom Metrics

  • Memory e Disk Space
  • IAM = Permitir PutMetricData, GetMetricStatistics e ListMetrics
    • Service = CloudWatch
  • É possível passar os valores estatísticos "na mão"
    • ex. métrica a nível de segundo, evitar cobrança de muito PutMetricData
    • --statistic-values Sum=11,Minimum=2,Maximum=5,SampleCount=3 --timestamp x
  • Limite de 10 dimensions
  • entre 2 semanas no passado a 2 horas no futuro

Detailed Monitoring

  • Mais métricas
    • Dimensiosn AMI ID e Instance Type
    • Agg by AMI id
    • Agg by instance type

Trusted Advisor

  • Global
  • Cost Optimization, Performance, Security, Fault Tolerance

CloudWatch Logs

  • Log group = streams de logs relacionados
    • Retenção, monitoramento, controle de acesso
  • VPC Flow Logs = 1 log stream por ENI
    • Filtrar ACCEPT ou REJECT ou ambos
    • Manda pro CW Logs ou S3
    • IAM Role: DescribeLogGroups, DescribeLogStreams, CreateLogGroup, CreateLogStream, PutLogEvents
  • Subscription nos logs
    • Enviar para ES ou Lambda
    • Pro ES basicamente a AWS cria uma lambda pra vc
  • Exportar para um bucket no S3 para essa conta ou outra
    • Precisa de uma policy permitindo
  • LogGroup => LogStreams => LogEvents

Metric Filters

  • É possível criar filtros para os logs do CW e gerar uma métrica em cima dos resultados
  • Pesquisar "400" ou extrair algo dos logs
    • [host, logName, user, timestamp, request, statusCode=4*, size]
  • É possível usar um valor constante para a métrica ex 1 para saber quantos requests retornaram 4XX
  • Ou usar uma variável ex $statusCode pra ter métrica de todos os status codes retornados

ElasticSearch

  • Domain = coleção de recursos pra rodar o cluster
  • Kibana = GUI no topo do ES, visualizar os dados
  • ES = NoSQL com indices para examinar os dados
  • Logstash = parecido com o CW Logs Agent, stream
    • Passar os logs para uma stash (elasticsearch)

Domain 5: Incident and Event Response

AWS Systems Manager

Overview

  • Problema = migração pra cloud, ferramentas de gerenciamento de VM não se aplicam à cloud

  • Documents = core do SSM, JSON

  • Run command = executa um comando uma vez em uma ou mais máquinas

  • Automation = configura um workflow (ex. recuperar uma EC2, construir golden AMI)

  • State Manager = detecta drift nas instâncias onde a configuração desvia de uma regra

    • Manter instâncias alinhadas com a configuração base

  • Maintenance window = janela p/ updates

    • utiliza c/ State Manager, Patch Manager

  • Inventory = catálogo

    • Integra com AWS Config para ver as mudanças com o tempo
    • Trigger com CloudWatch Events

  • Patch Manager = criar patches para windows e linux

  • Parameter Store = Centralizar parâmetros dos outros componentes

  • Resource Groups = Uma aplicação ou camada da aplicação

  • Insights = Gerenciar e operar grupos de recursos

    • Precisa ter o resource group pros Insights funcionar
    • Visualizar dados
    • Responder e automatizar ações operacionais

  • 3 categorias

  • Deploy, Configurar e Administrar

    • Run Command
    • State Manager

  • Shared Capabilities (utilizadas em outros componentes)

    • Mainenance Window
    • Parameter Store

  • Rastrear e atualizar

    • Inventory
    • Patch Manager
    • Automation

Agent

  • Instalado nas EC2 ou on-premises
  • Instalado por default
    • Windows Server 2019 e 2019, e 2003-2012 R2 criadas depois de Nov. 2016
    • Amazon Linux (1 e 2), Ubuntu Server 16.04 e Ubuntu Server 18.04 LTS
  • On premises e outras AMIs instalar na mão

Console Insights

  • Resource Groups
    • Obrigatoriamente precisa de uma tag, mas não de um valor
    • Vai pegar todos os recursos com aquela tag (e opcionalmente com aquele valor)
    • Também dá pra passar uma stack CloudFormation
    • Tagging a nível de resource groups, por ex. depois para aplicar um patch
    • Executar automação dentro do grupo
  • Insights
    • Built-in Insights = AWS Config, CluodTrail, Personal Health e Trusted Advisor
    • Dashboard by Cloudwatch = Dashboard embedded

Inventory

  • Fica dentro dos insights
  • Especificar o target
    • Todas as instâncias gerenciadas
    • Especificar tag
    • Selecionar instâncias manualmente
  • Schedule = Agendar tempo de scraping
  • Parâmetros = Tipos de dados que você quer catalogar
  • Aciona o documento AWS-GatherSoftwareInventory

Automation

  • Tarefas = conjunto de passos em um Document
  • Elimina o uso de um bastion host, abrir portas, diferenciar entre RDP e Linux, etc
  • Document
    • JSON definindo os parâmetros, passos pra executar uma ação e saídas
    • Alguns documentos rodam tanto pra Windows quanto pra Linux
  • AWSSupport documents = gerenciar incidentes
    • EC2 não está respondendo, executar o AWSSupport-ExecuteEC2Rescue
  • Run Command = Executa um Document instantaneamente
    • Documentos de Automation e Run são diferentes, pois automation são atividades específicas
    • Maintenance Window integra com Run Command
  • Session Manager
    • Acessar instâncias sem precisar abrir portas ou gerencias bastion hosts

Patch Manager

  • EC2 ou On Prem
  • Ter certeza que as instâncias estão compliant com algum requisito
  • Aplicar patches de segurança em uma janela
  • Patch baseline
    • Built in ou custom
    • Patches built-in apenas para atualizações de segurança críticas
  • Patch groups baseados em instâncias taggeadas
  • AWS-RunPatchBaseline
    • Windows e Linux
    • ApplyPatchBaseline é legado, apenas p/ Windows
    • Workflow: Configuração de uma baseline para as instâncias
    • Grupos: Dev, Homolog, Prod
    • Run Command com a patch baseline
    • Operation = O que você quer fazer
      • Scan = verificar compliance da instância com os patches
      • Install = instala o patch
  • Se a instância tiver um patch group, usa o group da instância, caso contrário usa a baseline da aws
  • Maintenance window
    • Criar uma schedule, com sintaxe de cron ou rate
    • Duração, se a manutenção está levando mais do que o esperado, adiciona estado de incompleto
  • É possível integrar os eventos do System Manager com CloudWatch Events
  • Distributor: bundle de arquivos de aplicação
    • Estilo um CodeDeploy
    • Mais para software com agent
      • CloudWatch Agent
      • Bootstrap instâncias, aplicar mudanças

SSM Hands-on

  • Para habilitar o SSM, é necessário adicionar uma role/instance profile, com as seguintes policies:
    • AssumeRole para ec2.amazonaws.com
    • arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
    • Caso esteja usando VPC Endpoint (subnet sem NAT), liberar acesso para os seguintes buckets
      • arn:aws:s3:::patch-baseline-snapshot-region/*
      • arn:aws:s3:::aws-ssm-region/*
    • Caso irá usar um bucket S3 para as operações do Systems Manager, adicionar permissão pro bucket também. Exemplo de utilizações:
      • Scripts no bucket para usar nos comandos
      • Gravar saída dos Run Commands
      • Acessar patch lists customizadas
    • Caso irá adicionar uma instância EC2 em um diretório do Microsoft AD, adicionar a policy arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
    • Caso irá utilizar o CloudWatch Agent para exportar métricas, adicionar a policy arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
  • Habilitar SSM on-premises

Explorer

  • Visão agregada de OpsData (operations data) e OpsItems (operational work items) para as contas AWS

CloudTrail

  • Trail = optionally global (default)
  • Record data events (s3 buckets ou lambda)
  • Storage location = new bucket ou existing
  • Dá pra desabilitar temporariamente
  • Dá pra enviar pro CloudWatch Logs
    • Metrics, alarms
    • Precisa de CreateLogStream e PutLogEvents

CloudWatch Alarms

  • Baseados em métricas e períodos
    • Statistic e threshold
  • SNS quando está em um BREACHING
  • Autoscaling
  • Create Alarm direto no console da EC2
  • Toggle "ActionsEnable" para 'desligar' o alarme
  • Via CLI = set-alarm-state
  • Actions = AS ou EC2-based
  • AS Actions
    • Scale Out e Scale in
  • EC2 Actions
    • ???
  • Billing alarms
    • Precisa estar em us-east-1 e ser conta root
    • Por serviço ou estimativa de custo
    • Cost allocation tags, filtrar por Usage Type
  • 5000 alarmes
Raw
07-exam-readiness.md

AWS Training - Exam Readiness

Instructor: Alex Galvin

Fundamentos da prova

  • Entender, não memorizar
  • Cuidado com distratores nas questões
  • Practice exam não diz as respostas certas, apenas um overview nos domains
  • Pontos chaves:
    • Análise dos principais pontos das questões
    • "Ingredientes" e "Solicitações" de cada pergunta
    • Modificadores mudam as solicitações
  • Leia todas as alternativas
  • Pare de ler quando achar o que está errado - não se convença de que "teoricamente isso poderia funcionar"
  • Preferência sempre pela resposta mais simples e tecnicamente correta

Domain 1: SLDC Automation

Gerenciamento do ciclo de vida das aplicações

  • CI = Source -> Test
  • Continuous Delivery = Source -> Deploy (Aprovação manual)
  • Continuous Deployment = Source -> Deploy (Automatizado)
  • Automatizar todas as etapas
  • CodePipeline = Action Provider = Manual Approval
    • SNS topic
  • CI/CD: Serviços da AWS ou não
  • CD Flow
    • Commit VCS
    • Pull no servidor CI
    • Builds distribuídos e testes paralelos
    • Report para o dev, abortar em caso de falha
    • Gerar artefato
    • Push
    • Configurar builder de pacote
    • Build
    • Armazenar artefato
  • CI Goals:
    • Gerar uma release ao fazer check-in
    • Build e testes consistentes e repetíveis
    • Artefato pronto para o deploy
    • Feedback loop
  • CD Goals:
    • Deploy para staging automático
    • Deploy para prod seguro e sem downtime
    • Entrega mais rápida = Maior frequência de deploy
    • Menor lead time e taxa de falhas
  • Infra imutável = Mudanças apenas pela pipeline

Code Services

CodeCommit

  • Repositório Git
  • Ajuda com objetivos de CI/CD
  • IAM
  • Altamente disponível e durável
  • Entender os benefícios vs self-hosting => >>Homework<<
  • Branches e git flow
  • Integração entre code services = CloudWatch Events
    • Push -> CodeCommit -> Notificar CW Events -> Iniciar CodeBuild

CodeBuild

  • Infra escalável
  • "Jenkins serverless"
  • Debug local c/ CodeBuild Agent => >>Homework<<
  • Entender buildspec.yaml => >>Homework<<
    • Variáveis de ambiente
    • Fases
    • Pre/Post buildd
    • Comandos
    • Artefatos
  • Como ele interage c/ outros serviços? => >>Homework<<
    • Quais componentes e artefatos ele pode usar?
    • Passos após o build
  • Alternativas => Jenkins
    • Como migrar, como deixar altamente disponível
    • Plugin para EC2 e para CodeBuild

CodeDeploy

  • Deploy direto para EC2 (e outros serviços)
  • Agent nas instâncias
  • Instala ou atualiza aplicações, verifica-as
  • Não faz configuração do sistema
  • Tipos de deployment => >>Homework<<
    • One at a time
    • Half at a time
    • All at once
  • Rollback / Redeploy
  • appspec.yml
    • Version: 0.0
    • Suporta Windows e Linux
    • Especificar os arquivos para instalar
    • Hooks e scripts
  • Revisões = Source code + Appspec
  • Conhecer o workflow, como configurar e as interações => >>Homework<<
  • Orquestração com CodeBuild
    • Lambda = complexo
    • CodePipeline = melhor alternativa

CodePipeline

  • Ações automatizadas -> Check-in para prod
  • Rodar sempreq ue o código mudar
  • Action para aprovação manual
  • Ações feitas e serviços suportados
    • Source
    • Build / Test
      • CodeBuild
      • Jenkins
    • Deploy
      • CodeDeploy
      • CloudFormation
    • Invoke (Lambda)
    • Approval (SNS)
  • Multi-pipeline integration
    • Cross-account
    • Source = S3
    • Deploy = CodeDeploy
    • Test = Invocar Lambda
    • KMS => Criptografar conteúdo da pipeline

Testes

  • Testes unitários
  • Escolher espostas que garantam a cobertura do código
  • Testes de integração
  • Performance
  • Testes de infra
    • Não introduzir vulnerabilidades
    • Carga e penetração
  • Testes de regressão
    • Rodar novamente todos os testes
    • Garantir que alteração não quebrou nada
  • Keyword: Test Driven Development
    • Testes antes do código
    • Boa cobertura / Falhar rápido
    • Ênfase em testes unitários sobre outros testes
    • Testes independentes
  • Testes de integração
    • Mais complexos, dependentes
    • Detecta bugs em integração entre módulos
  • Tolerância a falhas
    • Mesmo se não especificado, escolher a resposta com melhor tolerância a falhas
    • Cenário de testes = desligar as coisas

Estratégias de deployment

  • In-place = Swap entre código antigo e código novo
    • Gera downtime
    • Pode não aparecer muito, geralmente é pra sair dele para uma alternativa melhor
  • Rolling = Derrubar instâncias, X por vez
    • Aplicação fica em estado degradado, porém cost-effective
  • Canary Rolling = Atualizar parte dos recursos no ASG
  • Blue/Green AKA A/B Deployment = Que mais aparece
    • Ambiente inteiro duplicado
    • Autoscaling = menor custo
  • Red/Black Deploy = Trocar ASG
  • Immutable / rolling = Substituir instâncias antigas

Domain axioms

  • Entenda os serviços "Code"
  • Aplicar atualizações e se recuperar
  • Conhecer as estratégias e como implementar e troubleshoot
  • Teste tudo
  • Automatize tudo

Questões de exemplo

  1. Garantir credenciais não são *commitadas
  • Pre-commit hook para parar no dev
  1. Apenas usuários autorizados podem acessar o CodeBuild e armazenar artefatos de forma segura
  • Segurança através de variáveis de ambiente não é muito segura
  • Bucket criptografado
  • IAM role
  1. Reduzir custos com Jenkins
  • EC2 plugin
  1. Renomear lambda c/ CodeStar
  • Template.yml = configurações do projeto
  • Alternativas com passos manuais geralmente estão erradas

Domain 2: Configuration Management and Infra as Code

  • Mesmos conceitos do gerenciamento do código da aplicação para infra

CloudFormation

  • Entender as partes do template (Resources, Parameters, etc)
  • Atualizando stacks - Change Sets
  • UpdatePolicy
  • Execução paralela, a não ser que tenha um DependsOn configurado
  • WaitCondition e WaitCondition Handle
    • Usar WaitCondition em vez de CreationPolicy = Fora do ASG ou fora da stack
  • Stack policies = Uma vez definida, deny all por padrão
  • Custom Resource
    • Service Token
    • SNS ou Lambda
  • StackSets = Cross region ou Cross account
  • Scripts
    • cfn-init => extensão do user-data
    • cfn-hup => monitorar mudanças em metadados
      • Por padrão atualizações no Metadata não vão triggar a stack update
      • Ex: Não atualiza a EC2 se não tiver o cfn-hup configurado
    • cfn-signal => indicar estado para CreationPolicy ou WaitCondition
    • cfn-get-metadata => pegar dados sobre a stack

Deployment Options

  • Template = code = ci/cd workflow
  • Criar EB ou OpsWorks

Elastic Beanstalk

  • Conhecer os diferentes componentes
    • Env
      • Tiers (Web & Worker)
      • Tipo (Single, HA)
      • 1 app por env
    • Versões da aplicação
      • Armazenado no S3
      • Diferentes versões em envs diferentes
      • Rollbacks e rolling updates
    • Config (ebextensions)
      • Serviços AWS
      • Programas do yum ou daemons
  • Opções de deployment
    • In-place
    • Env Swap (blue/green)
      • eb clone -n green
      • eb deploy green
      • eb swap blue --destination-name green
  • Não são feitas muitas configurações no OS
  • ebextensions - >>Homework<<
  • Entender containers, ECS e multi-docker

OpsWorks

  • Puppet, Chef ou Stacks
  • Conhecer lifecycle events
    • Setup = Configuração inicial de uma máquina nova
    • Configure = Executado em todas as máquinas, sempre que uma máquina fica on/off. Usado pra configurar DNS ou service discovery
    • Deploy = Criação ou atualização de uma app
    • Undeploy = Remoção de uma app, parar serviços, limpeza
    • Shutdown = Desligamento de uma EC2

Containers

  • ECS, EKS, Fargate

Serverless

  • Lambda = Ferramenta organizacional
  • API Gateway = Rest e Websocket

Domain axioms

  • Alta % de questões
  • Conhecer cloudformation em profundidade
  • Quando usar CFN, OpsWorks ou EB
  • Entregar uma pipeline de CI/CD com Docker
  • Rotear porções de usuários => Route53

Questões de exemplo

  1. UPDATE_ROLLBACK_FAILED - causa?
  • Recurso alterado fora do cfn
  1. Blue/Green sobre as próximas 24h - Rollback rápido
  • Blue/Green não é só swap, pode ser lento / canary
  • Se a alternativa fala "Usar 'xxx' para migrar a aplicação..."
    • Ele realmente suporta migração? Ou teria que reescrever tudo?
  1. Por que não podemos deletar a stack?
  • Termination protection para stack cloudformation
  • VPC c/ recursos atachados
  1. EB + SQS + Deploy
  • Não existe feature de importação no EB
  • Worker env conectado com SQS automaticamente
  1. A/B deploy sobre as próximas 24h, rollback fácil
  • ALB não consegue fazer controle de tráfego
  • Route53 Weighted Routing
  1. Atualização de código CloudFormation levando 15 minutos
  • Aumentar o MaxBatchTime = update mais demorado
  • Intervalo padrão do cfn-hup = 15 minutos

Domain 3: Monitoring and Logging

CloudWatch

  • Dados de métrica retidos por 15 meses
    • Ficam menos granulares conforme o tempo passa
  • Métricas do ELB
    • SurgeQueueLength = Número de requisições enfileiradas para o ELB
      • Aumento = Back-end não consegue aguentar a carga
      • Fila aumenta, requisições são dropadas
    • SpillOverCount = Número de requisições dropadas
    • Backend connection errors = Warmup do ELB
  • Esteja familiar com - >>Homework<<
    • Erros 4XX e 5XX
    • Back-end vs ELB

CloudWatch Logs

  • Ec2 e on-prem
  • CloudTrail -> CloudWatch Logs
  • VPC Flow e ELB Access Logs
  • ELB Logs
    • 1 arquivo por node
    • A cada 15 minutos +-
    • Informações: client:port, tempo de processamento da req & res, req, ARN do cert
  • Foco em gerar logs
    • Organizar, analisar, usar com componentes e automação
    • Consumir dos serviços

CloudWatch Alarms

  • Conhecer trigger actions - >>Homework<<
  • Saber construir e configurar - >>Homework<<

CloudWatch Events

  • Quase real-time
  • Regras -> Combinação -> Funções
  • Targets
    • EC2
    • Lambda
    • Kinesis Stream
    • ECS
    • Step Function
    • SNS
    • SQS

CloudTrail

  • Registrar atividade de API, login no console
  • Quem, o que, quando, onde e resposta retornada
  • Possível consolidar entre várias contas
  • Integração nativa c/ CW Logs
  • Validação do log file para garantir integridade e autenticidade

AWS X-Ray

  • APM, bottlenecks, insights
  • Entender o serviço, usos e como interagir c/ CW Logs

Monitorando CI/CD

  • Que tipo de logging, que informações, métricas - >>Homework<<
  • CodeCommit -> SNS ou Lambda Invoke
  • CodeBuild -> Notificações do estado do build
  • CodeDeploy -> Antes, durante e depois do deploy (SNS)
  • CodePipeline -> Notificação de alteração do status
    • Pipeline, Stage ou Ação

Logging

  • CloudTrail p/ CW Logs - >>Homework<<
  • CW Logs -> Armazenar no S3 para avaliação eventual
  • Log Events -> Log Streams -> Log Groups
  • VPC Flow Logs
    • Trafico de/para subnets e ENIs
    • Ingerido para o CW Logs
    • Streams por ENIs

Kinesis

  • Não é para monit, mas pode ajudar c/ ingestão e análise
  • Data Streams
    • Escalável, ingestão e processamento de muitas informações de logging
    • Dashboards real-time
  • Firehose
    • Stream para o armazenamento (ex. S3)
    • Processar dados com AWS ou ferramenta de terceiros
  • Data Analytics
    • Processamento real-time c/ SQL

Centralized Logging

  • Conta -> CW Log Subscription -> CW Log Destination
  • Destination -> Kinesis Firehose -> S3 -> Glacier

Melhores práticas

  • Logar e monitorar TUDO
  • Definir e reforçar padrão de tags
  • Como reforçar

Domain axioms

  • Conheça monitoramento, logging e tagging profundamente
  • COnheça CloudWatch profundamente
  • Diferença entre opções de logging, qual é mais cost-effective
  • Reportar em API Calls => CloudTrail
  • Entender tagging

Questões de exemplo

  1. Auditoria - dar acesso ao auditor
  • Se você der acesso ao sistema pro auditor, ele vai te falhar na hora
  1. Tempo de resposta alto c/ AS
  • Monitoramento detalhado = intervalo de 1 minuto
    • Não te dará métricas sub-minuto
  1. Latência de 1 minuto, o que não ajudaria
  2. Monitorar 404s
  • Nem toda aplicação tem ELB!
  • Considerar real-time
  1. Tempo de resposta alto, cpu alto para app web

Domain 4: Policies and standards automation

  • Conhecer m étricas para serviços gerenciados - >>Homework<<
  • Otimização de custo por automação
  • Implementar estratégias de governança

IAM - Big picture

  • Users = Credenciais permanentes
  • Groups = Melhor prática
  • Roles (Serviços)
    • Temporários
    • Autenticação
  • Policies para garantir autenticação
  • Use roles sempre que puder
    • Difícil ter uma questão onde terá que escolher "user" sobre "role"
  • Requisitos da role: Trusted Policy (quem pode assumir) e Access Policy (IAM Policy)
  • IAM Conditions
    • Multifactor Auth - Apenas para usuários

Proteção dos dados

  • Responsabilidade do cliente
  • Considerar segurança mesmo em questões que não focam em segurança
  • Criptografia em trânsito
    • Do cliente para o endpoint
    • TLS => ACM
    • DirectConnect ou VPN

Data in flight

  • SSL Termination com Load Balancer
  • Conexão HTTP/SSL
  • End to End Encryption = Gerar outro certificado p/ criptografar comunicação do ELB para a EC2
  • Cloudfront também criptografa

Controles de perímetro de rede

  • Network ACL
    • Proteção do perímetro
    • Subnet e tudo dentro dela
    • Stateless = Precisa do inbound e outbound
    • Regras apenas para IP
    • Regras em ordem (1, 2, 3..)
  • Security Groups
    • Proteção da ENI
    • Stateful = Inbound ignora outbound
    • Comunicação/regras entre serviços
  • Host firewalls
    • Iptables

Data in transit

  • Também é responsabilidade do cliente
  • S3 SSE
    • KMS
    • S3
    • C
  • Glacier = único serviço que criptografa por default
  • EBS = Criptografia do volume root e discos adicionais
  • Detecção de intrusão de rede = GuardDuty
    • Vigia tráfego de rede
    • Auto-analisa: CloudTrail, VPC Flow, DNS Query logs
    • Notificações em cima de desvio de padrões

Amazon Inspector

  • Escaneamento de vulnerabilidades dentro de instâncias EC2
  • Agent
  • Notifica ou corrige com serviço de gerência de configuração (ex. SSM)
  • Regras para dizer com o que você se importa
  • Ruleset padrão ou personalizado

Systems Manager

  • Agent
  • On premises e cloud
  • Linux e windows
  • Possível criar AMIs (SSM Automation)
  • Se familiarizar com todos os serviços e o que eles fazem - >>Homework<<
  • Conheça profundamente alguns dos serviços - >>Homework<<
    • Run Command
    • Patch Manager
    • Parameter Store

Run Command

  • Rodar script em toda a frota, sem logar em cada uma delas
  • Automar grande grupo de infraestrutura
  • Comandos pre-build ou personalizados

Patch Manager

  • Ajudar com processamento e atualização dos sistemas
  • Deploy de patches de OS ou software em toda a frota
  • Agendado ou via janela de manutenção
  • Nível de severidade
  • Log de audit para atualização

Parameter store

  • Armazenar valores de configuração
  • Criptografar e descriptografar com KMS
  • Serviços adicionais:
    • Secrets manager
      • Para senhas e credenciais
      • Rotação automática
      • Custo adicional
    • License Manager
      • Licenças de software (Windows, Office)
      • Rastrear onde estão sendo usadas

AWS Config

  • Regras para monitorar e gerenciar configuração
  • Descobrir novos recursos e adicioná-los em grupos
  • Monitorar e reforçar padrões
  • Saber quem fez alteração, o que e quando mudou
  • Conhecer o setup -- Como usar e visualizar - >>Homework<<
    • Ver todos os rulesets
    • Deep dive

Otimização de custos

  • Ter em mente para todas as questões
  • Trusted Advisor
    • Reduzir custos, aumentar performance e segurança
    • Limites de serviços
    • Alarmes e notificações - >>Homework<<
  • Tagging para gerenciamento de custo
    • Desligar instâncias por tags

Governança e compliance

Service catalog

  • Padrões e limites em quem e quando podem lançar serviços
  • Self-service para usuários finais
  • AWS, 3rd-party e customer based
  • JSON ou Yaml
  • Estudar: Como usar e como controlar acesso - >>Homework<<

EC2 Instance Compliance

  • Restringir lançamento com AMI personalizada
  • Golden Image
  • Compartilhar com outras contas -- descompartilhar a AMI antiga para evitar uso
  • CM => OpsWorks ou Puppet
  • Nunca queira ter passos manuais

Domain Axioms

  • Conheça o AWS Config e Inspector
  • Saiba como gerenciar acesso aos serviços
  • Conheça os serviços de CM e como eles se diferenciam (puppet, chef, ansible)
  • SSM in-depth
  • Criptografia

Practice Questions

  1. Criptografia @ rest e in-transit
  • ELB para EC2 sem criptografar = não é bom / end-to-end
  1. Admin saiu c/ root access e credenciais de usuário - o que fazer
  • Restrição de IP no usuário root = não é possível
  • Roles = credenciais temporárias, não precisa rotacionar
  1. Auto-patch e gerar lista de compliance
  • Variável de ambiente na Lambda com chave SSH = Não é muito seguro
  • Alternativa melhor seria Parameter Store
  1. Automatizar golden AMI
  • Menos complexo
  • Automation Documents
  • CodeDeploy não pode criar AMIs

Domain 5: Incident & Event Response

  • Automatizar todas as áreas da sua infra e arquitetura

Troubleshooting tips

  • Estratégias de logging
    • Centralizar
    • Padrões de acesso (Quem, quão rapidamente)
    • Como os logs vão do sistema p/ armazenamento
    • Retenção / lifecycle
    • Análise histórica a longo prazo
  • Coletar e agregar dados
    • CloudWatch <-> X-Ray
    • Como serviços podem trabalhar juntos para dar resultado de observabilidade
    • Como informações adicionais podem ser necessárias e como obtê-las
    • Ex: Notificar chamadas de API do usuário root
      • CloudTrail p/ CW Logs
      • Metric Filter
      • Alarm -> SNS -> Tomar ação
    • Analsar logs de aplicação, infra e OS
      • Configuration Management -> OpsWorks, EB, CFN
    • Ciladas nos sistemas
      • Instância, rede, disco, rds, rbac
      • Ler guias de troubleshooting nas documentações

Healing automatizado

  • CloudFormation: Configurar alarme trigger para relançar infra baseado em template
  • EB: Menos complexo
  • OpsWorks: Auto healing
    • Combinar com cfn
  • Pegar dados de logs destes

AutoScaling & Lifecycle hooks

  • Que ações podem ser influenciadas ou tomadas
  • Suspender processos: Como, pq, efeitos
    • Launch
    • Terminate
    • AddToLoadBalancer
    • AlarmNotification
    • ReplaceUnhealthy
    • HealthCheck
    • AZRebalance
  • Detachar e colocar de volta
  • Estados stand-by
  • Termination Policies
    • Default = AZ, Oldest LC/LT, Closest billing hour
    • Cai bastante
  • Lifecycle Hooks
    • Colocar ações em hold e triggar outras ações
    • Pending:Wait -> Instalar software
    • Terminating:Wait -> Pegar logs
  • Scaling Policies
    • Step Scaling -> Política de escala baseado em alarme, com steps baseados no breaching threshold
    • Simple scaling -> Política padrão, baseada em alarme
    • Target Tracking -> Próprio Auto Scaling rastreia a métrica e define os alarmes HIGH e LOW
  • Conhecer todos esses conceitos profundamente -> >>Homework<<
    • O que pode ser desabilitado, suspendido, etc
    • Escalar em 2 ou mais métricas
    • Scale out cedo e rápido, scale in lentamente
    • Lifecycle Hooks
  • ELB - Suspend -> >>Homework<<
    • Desabilitar AZ (não irá rotear requisições)
    • Slow Start Mode -> Ramp-up para targets, para que eles não sejam sobrecarregados com requisições
    • Deletion Protection

CodeDeploy & AutoScaling

  • Entender todos os eventos
    • Você consegue controlar:
      • ApplicationStop
      • BeforeInstall
      • AfterInstall
      • ApplicationStart
      • ValidateService
    • Você não consegue controlar
      • Start
      • DownloadBundle
      • Install
      • End
    • Trigar lifecycle da aplicação baseado neles
    • Integrar hooks e instance health
      • ValidateService = Seu problema
      • Antes do healthcheck do Load Balancer

Domain axioms

  • Entenda todos os processos
  • Auto recuperação
  • Arquiteturas de logging
  • Suspender processos do LB e AS

Questões de exemplo

  1. EC2 tagging, audit & terminate
  • AWS Config = Mais simples
  • IAM Policy para reforçar criação com tags é OK
  1. Terminado enquanto processava -- asg
  • Desabilitar ApiTermination (Termination Protection) não funciona com o ASG
  • Colocar a instância em StandBy quando for processar
  1. Integridade do S3 e deploys seguros
  • MFA & IAM Roles
  1. CodeDeploy - EC2 Falhando - ASG
  • Suspender ReplaceUnhealthy ou Healthcheck
  • Validar código no CodeDeploy

Domain 6: HA, Fault Tolerance e DR

  • Sempre pensar sobre HA, mesmo quando a questão não perguntar
  • Implementar multi-az e multi-region
  • DNS Failover

Serviços multi-ambientes

  • EC2 = AMI copy
  • EBS = Cross-region snap copy
  • S3 = Cross region replication
  • RDS = Cross region snap copy ou Cross Region Read Replica
  • Dynamodb = Global Tables ou Streams
  • Aurora = Global Tables

Escalabilidade

  • ASG
  • Lambda@Edge = CloudFront p/ fazer cache das requisições
  • SQS Decoupling
    • Comunicação de 2 vias = 2 filas
  • SNS Fan Out = 1 tópico -> Múltiplas queues
    • 1 fila p/ processamento, outra fila p/ data warehousing
    • SQS -> Subscribe queue to SNS topic
  • Storage scaling
    • S3 = Autoscalable por default
    • S3 = conteúdo estático
    • CloudFront
    • EBS = Ajustar tamanho ou performance sem parar
  • RDS
    • Escala horizontal dinâmica não é opção
    • Read replicas se suportada pela engine (todas suportam)
    • Elasticache
  • Dynamodb
    • Escala = ajustar read/write capacity
    • Cache = DAX
      • Read-heavy ou bursty workloads
      • Aceleração em memória

Disaster Recoevry

  • RPO = Quanta perda de dados você pode ter
  • RTO = Quanto downtime você pode ter
  • Métodos
    • Backup & Restore
      • RPO/RTO em horas
      • Preocupa-se em salvar informações
    • Pilot Light
      • RPO/RTO em minutos
      • Salvar dados e manter core rodando
      • Quando disastre ocorrer, escalar
    • Warm Standby
      • RPO/RTO em segundos
      • Recursos críticos de negócio rodando em escala normal
    • Hot standby
      • RPO/RTO quase real-time
      • Auto failover
      • Ambiente rodando em escala total
  • Melhores práticas
    • Começar com backups e trabalhar no compute
    • Game days
    • Cuidado com problemas de licença de software

Falha

  • Design para falha
    • Como a arquitetura reagiria em falha de componentes
    • Replicação e distribuição de workloads
  • Nunca escolha a resposta com passo manual

Domain Axioms

  • Resiliência a falhas
  • Escalar em métricas não-ec2
  • Desacoplamento
  • Ferramentas para ajudar com componentes não-escaláveis
    • Cache e EIP
  • ELB e AS trabalhando juntos

Questões de exemplo

  1. EC2, RDS, Escala
  • ELB não suporta UDP
  1. Lentidão causada por muito tráfego
  • Atachar outra ENI não ajuda a melhorar a vazão ou banda larga de rede
    • Use case para atachar outra ENI = failover
  • SurgeQueue = métrica, não feature
  • EB pode escalar baseado em tempo de carga e requisição por segundo
  1. Troubleshoot problema de download do S3
  • Check logs

Outros

  • KCL = Kinesis Client Library = SDK para escrever consumers
  • RDS possui notificações para o SNS
    • Inclui notificações de disponibilidade (banco parou, subiu, etc)
  • CloudTrail = Delay de até 15 minutos, não é real-time
  • Notificações de compliance change no Config = CW Eevents
    • SNS vai mandar tudo
  • RDS Auto Snapshots = 1 vez por dia
    • Copiar snapshots manuais e automáticos
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment