Please enable JavaScript.

Coggle requires JavaScript to display documents.

AWS (ELB, ASG, EBS (:fire: Instance Store (Desvantagens (Quando a…

- - - - Servidores que distribuem o tráfego entre instâncias EC2
      - Somente o DNS do Load Balancer é visto pelos usuários
      - Para de enviar tráfego imediatamente para instância que apresentam problemas (healthcheck)
      - Oferece SSL (HTTPS)
      - Opção STICKNESS com cookies
        
        Uma vez que o cliente acessou uma instância ele vai usar sempre a mesma instância
      - Alta disponibilidade com Availability zones
      - Verifica regularmente healthcheck
        
        É executado em caminho e porta específico
        
        Se a resposta não for 200 ela para de receber tráfego
      - Separa tráfego público para privado
      - Vantagens
        
        É gerenciado pelo AWS
        
        Manutençoes e upgrades
        
        Integrado com outros serviços AWS
      - Tipos de Load Balancer
        
        Classic Load Balancer
        
        Obsoleto
        
        Application Load Balancer
        
        Load balancing múltiplas aplicações HTTP em máquinas diferentes (Target Groups)
        
        Load balancing múltiplas aplicações HTTP na mesma máquina (containers)
        
        Load balancing baseado em rotas (URL)
        
        Load balancing baseado em hostname (URL)
        
        Boa para aplicações rodando em containers
        
        Possui recurso Port Mapping para redirecionar para porta dinâmica
        
        Stickness pode ser habilitado no Target Group
        
        Suporta HTTP/HTTPS e protocolo websockets
        
        A aplicação não vê o endereço IP da máquina cliente
        
        O endereço IP do cliente é inserido no header X-Forwarded-for
        
        Também é possível receber Port (X-Forwarded-Port)
        
        Proto (X-forwarded-Proto)
        
        Network Load Balancer
        
        Direciona tráfego TCP para instâncias
        
        Capacidade para milhões de requisições por segundo
        
        Suporta IP estático ou Elastic IP
        
        Menor latência: ~100ms (vs 400ms for ALB)
        
        NLB é usado em aplicações com alto volume de tráfego
        
        ALB é suficiente para a maioria das aplicações
        
        Mesmo processo de criação do ALB
      - É possivel configurar um load balancer para rede publica e privada
    - - Classic Load Balancer - Ultrapassado, não usar
      - ALB para HTTP/HTTPS e websockets
      - NLB para TCP
      - CLB e ALB suportam certificado SSL
      - Todos Load Balancer podem realizar health check
      - ALB pode rotear baseado em path e hostname
      - ALB é excelente para ser usado com ECS (docker)
      - Todos possuem DNS, não utilizae IP
      - ELB é escalável, mas não é muito rápido. É necessário fazer um warm-up.
      - NLB pode ver IP dos clientes
      - 5xx erros são da aplicação
        
        503 significa capacidade máxima atingida ou target não definido
        
        Se o Load Balancer não pode conectar com sua aplicação verifique o Security Group
    - - Colocar servidor atrás de um Load Balancer
      - Permitir acesso ao EC2 apenas pelo Load Balancer
      - ELB - Inspecionar o Target Group
  - - - Tráfego de um website ou aplicação variam
      - AWS permite criar e destruir instancias conforme a necessidade
      - Objetivo do Auto Scaling Group
        
        Scale out (criar instancias EC2)
        
        Scale in (diminuir instancias EC2)
        
        Definir minimo e maximo de instancias
        
        Registra novas instancias no Load Balancer
      - Atributos
        
        Launch Configuration
        
        AMI + Tipo da instancia
        
        EC2 USER DATA
        
        EBS VOLUMES
        
        SECURITY GROUPS
        
        SSH KEY PAIR
        
        Tamanho mínimo / máxima
        
        Informação sobre Network e subnets
        
        Informação sobre o Load Balancer
        
        Regras de escalonamento
      - Auto Scaling Alarms
        
        É um possível escalonar um ASG baseado em alarmes do CloudWatch
        
        Alarmes monitoram um Metric (ex. CPU)
        
        Podemos utilizar alarme para Scale in ou Scale out
      - Novas Regras
        
        É possível definir regras gerenciadas diretamente por Instancias EC2
        
        Regras
        
        Número de requisições ao LoadBalancer por Instancia
        
        Média de uso do CPU
        
        Média de tráfego entrando
        
        Média de trafego saindo
        
        Essas regras fazem mais sentido e são fáceis de usar
        
        Auto Scaling Custom Metric
        
        Quando precisa de uma metrica em especial
        
        Ex. Número de usuários conectados
        
        Enviar Custom Metric da aplicação EC2 para CloudWatch usando PutMetric API
        
        Cria um Alarme CloudWatch para monitorar valores altos e baixos
        
        Usar Alarme CloudWatch com Scaling Policy para ASG
    - - Auto Scaling pode ser acionado por uso de CPU, network, etc, ou pode ser acionado por Custom Metrics e também por agendamento
      - ASG usa Launch Configuration e podemos atualizar criando um novo Launch Configuration
      - IAM Roles anexados ao ASG será atribuido ao a instância EC2
      - ASG é grátis. É cobrado apenas os recursos lançados pelo ASG
      - Quando instâncias EC2 que foram inicializadas pelo ASG apresenta problema, ASG inicializará outra para substituir
      - ASG pode terminar instâncias identificadas com não-saudáveis pelo Load Balancer
  - - - EBS é um drive de rede (não um drive físico)
        
        EBS é usado AWS para acessar os dados. Isso significa que é um pouco mais lento que um driver local
        
        EBS pode ser desanexado de um EC2 e anexado a outro
      - Para guardar os dados da instancia usa-se EBS
        
        Instância EC2 pode terminar inesperedamente, quando ocorre um problema de hardware. Você recebe de um aviso
        
        Instância EC2 perde seu volume root quando são terminadas (opcional, mas vem por padrão)
      - EBS pertence a um Availability Zone
        
        Um EBS criado em um Availability Zone não pode ser associado a um EC2 em outra Availability Zone
      - Pode-se definir a capacidade (tamanho em GB ou IOPS)
        
        É cobrado pela capacidade escolhida
        
        É possível aumentar a capacidade depois que foi criado
      - Existem 4 tipos de volume EBS
        
        GP2 (SSD) General Purpose SSD. Meio termo entre preço e performance. (Usado para vários tipos de aplicação)
        
        IOI (SSD) - Alta performance, baixa latência e alto custo
        
        STI (HDD): baixo custo. Acesso frequente
        
        SCI (HDD) - Mais barato de todos. Acesso não frequente
      - Mudança de volume
        
        Depois de aumentar tem que redimencionar novamente
        
        Só é possível aumentar o volume de um EBS
      - EBS Snapshot
        
        Backup de volume
        
        Snapshot só faz backup do volume utilizado
        
        É usado para
        
        Salvar dados em caso de catástrofe
        
        Migração para um volume menor ou de outro tipo
        
        Criptografar um volume
      - Criptografia
        
        Quando um volume EBS criptografadao é criado
        
        Os dados são criptografados em repouso dentro do volume
        
        Os dados em movimento entre EC2 e EBS são criptografados
        
        Todos os snapshots são criptografados
        
        Todos os volumes criados do Snapshot são criptografados
        
        O processo é todo feito pela AWS. Totalmente transparente ao usuário
        
        Criptografia tem impacto minimo na latencia
        
        Criptografia EBS usa KMS(AES-256)
        
        Copiar um Snapshot permite que a cópia seja criptografada
    - - Volume EBS pode ser anexado somente a uma instância EC2 de cada vez
      - EBS é limitada a Availability Zone onde foi criado
      - Para migrar EBS de uma AZ para outra, é preciso fazer um snapshot do volume EBS e restaurar-lo em outra AZ
      - Backup EBS usa parte do IO que você provisionou. Backups não devem ser feitos durante período de tráfego intenso, pois podem afetar a perfomance.
      - Volume EBS root é terminado quando EC2 é terminado. É possível desabilitar essa função.
  - - - Melhor performance
    - - Quando a instância é terminada, todos os dados são perdidos
      - Não é possivel modificar o tamanho
      - Backup deve ser feito pelo usuário
- - - - É um DNS gerenciado pela AWS
      - Na AWS os records mais comum são
        
        A: URL para IPv4
        
        AAAA: URL para IPv6
        
        CNAME: URL para URL
        
        Alias: URL para recursos AWS
        
        Exemplo, se você requisitar um endereço para o DNS (www.example.com) ele vai te retornar o IP que a sua maquina precisa para se comunicar
      - Route 53 pode usar
        
        Public Domain Name que pertence a você (www.meusite.com)
        
        Private Domain Name que podem ser resolvidos pelas suas instancias EC2 dentro da sua VPC (App.empresa.internal)
      - Route 53 tem função avançada
        
        Load Balancing (usando DNS - também chamado de Client Load Balancing)
        
        Routing Policiy
        
        simple (que só pega o domain e retorna o endereço)
        
        failover (se não tiver uma resposta do servidor, pode enviar para outro)
        
        geolocation/geoproximity (escolher a resposta de acordo com o tráfego de uma região especifica)
        
        latency (redirecionar para o servidor com menor latencia)
        
        wheighted (balanceamento de acordo com a quantidade)
    - - Para recursos AWS use Alias ao invés de CNAME, para melhor perfomance
    - - Linkar o dominio a um recurso AWS
      - Registrar um dominio
  - - - RDS é um serviço gerenciado pela AWS para banco de dados que utilizam SQL
        para queries
      - Serviço de Banco de Dados Relacional
      - RDS suporta os seguintes Banco de Dados:
        
        Postgress
        
        Oracle
        
        MySQL
        
        MariaDB
        
        Microsoft SQL Server
        
        Aurora (Banco de dados desenvolvido pela AWS)
      - Vantagem de usar RDS vs EC2 e Banco de Dados
        
        Gerenciado pela AWS
        
        Patching é responsabilidade
        
        Backup continuo. Banco de Dados pode ser restaurado para um timestamp
        
        Painel de Controle para monitoramento
        
        Read Replicas para otimizar leituras
        
        Opção de configuração Multi Avaiability Zone para recuperação após disastres
        
        Janela de manutenção para upgrades
        
        Escalonamento (vertical e horizontal)
        
        Não é possivel SSH no RDS
      - RDS - Read Replica
        
        Até 5 Read Replicas
        
        Mesma AZ
        
        Diferente AZ
        
        Diferente Region
        
        Réplica is ASYNC
        
        Réplica pode virar Master
        
        Aplicações devem atualizar String de Conexão para usar Read Replica
        
        Você pode replicar banco de leitura para otimizar consultas
      - RDS - Multi Availability Zone
        
        Réplica é SYNC
        
        Um único DNS name.
        
        Automaticamente failover
        To Stand-by
        
        Aumenta disponibilidade
        
        Failover em caso de perda de AZ e rede
        
        Sem necessidade de intervenção
        
        Não é usado para escalonamento
      - RDS BACKUP
        
        Backup é habilitado automaticamente on RDS
        
        Snapshot do Banco de Dados
        
        Iniciado pelo usuário
        
        Snapshot pode ser guardado por quanto tempo o usuário quiser
        
        Backup automático
        
        Snapshot diário completo do banco de dados
        
        Registra log de todas as transações em tempo real
        
        Possível recuperar o Banco de Dados em qualquer timestamp
        
        7 dias de backup (pode ser aumentado até 35 dias)
      - RDS e CRIPTOGRAFIA
        
        Criptografia em repouso com AWS KMS - AES-256
        
        Certificado SSL para criptografar banco de dados em trânsito
        
        Para forçar SSL:
        
        PostgreSQL: rds.force_ssl=1 no console RDS (Parameter Group)
        
        MySQL de dentro do Banco de Dados entre: "GRANT USAGE ON . TO ‘mysqluser’’%’ REQUIRE SSL;"
        
        Para conectar usando SSL:
        
        Entre com o SSL trust certificate (pode ser feito o download no AWS)
        
        Entre com a opção SSL quando conectar ao Banco de Dados
      - SEGURANÇA no RDS
        
        Banco de Dados RDS normalmente é criado em uma rede privada e não publica
        
        RDS usa security groups da mesma forma que EC2 para definir regras de acesso
        
        IAM Policies define quem pode gerenciar dados no RDS
        
        Usuário e Senha podem ser usados para logar no Banco de Dados
        
        IAM users também pode ser usados para autenticar (MySQL e Aurora)
      - RDS vs Aurora
        
        Aurora é um Banco de Dados proprietário da AWS (não é opensource)
        
        Portgres e MySQL são suportados pelo Aurora (isso significa que os drivers Postgres and MySQL como se Aurora fosse Postgres ou MySQL)
        
        Aurora foi desenvolvido para as nuvens e AWS diz que é 5 vezes mais rápido que MySQL RDS e 3 vezes mais rápido que Postgres RDS
        
        Armazenamento Aurora cresce automaticamente em incrementos de 10GB, até 64TB
        
        Aurora pode ter até 15 Read Réplicas (sub 10ms) enquanto MySQL pode ter até 5
        
        Failover no Aurora é instantâneo. Usa HA nativo
        
        Aurora custa 20% mais que RDS, porém é mais eficiente.
    - - Criar banco de dados
  - - - ElastiCache é similar ao RDS. Oferece Banco de Dados gerenciados pela AWS
      - Duas opções disponíveis: Redis e Memcached
      - Caches são Banco de Dados na memória RAM, alta performance, baixa latência
      - Motivos para usar
        
        Ajuda a fazer sua aplicação Stateless
        
        Ajuda a reduzir a carga no Banco de Dados principal para leitura intensa
        
        Ajuda a aliviar a carga no RDS
      - Funcionamento
        
        Leitura escalona usando Read Replica
        
        Escrita escalona usando Sharding
        
        A aplicação faz o query para o ElasticCache, se não estiver disponível, faz o query no Banco de Dados RDS e armazena o ElasticCache
      - Multi AZ com Capacidade Failover
      - AWS cuida da manutenção, patching, otimização, setup, configuração,
        monitoramento, recuperação de falha e backups
      - Funcionamento com Session
        
        Usuário loga na aplicação
        
        Aplicação escreve os Dados da sessão no ElastiCache
        
        Usuário acessa a Aplicação por uma Outra instância
        
        Instância lê os dados Do cache e verifica que o Usuário já está logado
    - - ElasticCache - Criar cluster
    - - :pencil2:
        
        Redis é um Banco de Dados do tipo Key-Value que armazena os dados na RAM
        
        Latência muito baixa (sub ms)
        
        Cache não se perde quando instância é reiniciada (persistente)
        
        Ideal para
        
        Sessão do Usuário
        
        Alivia carga no Banco de Dados (ex. RDS)
        
        Leaderboard (Placar para jogos)
        
        Multi AZ com failover automático para recuperação de desastres se você não quiser perder seus dados.
        
        Suporta Read Replicas
    - - :pencil2:
        
        Memcached armazena objetos na memória RAM
        
        Cache perde os dados se for reiniciado
        
        Leitura rápida dos objetos armazenados
        
        AWS não vai perguntar qual é o melhor
  - - - VPC é criado dentro de uma Region
      - VPC contém subnets (redes)
      - Cada subnet é associada
        a um AZ
      - Subnet pode ser pública
      - Subnet pode ser privada
      - Pode-se ter várias subnets por AZ
      - Public Subnets podem conter
        
        Load Balancer
        
        Static Websites
        
        Files
        
        Public Authentication Layers
      - Private Subnets podem conter:
        
        Servidores Web
        
        Banco de dados
      - Public e Private subnets podem comunicar-se, se estiverem no mesmo VPC
      - Todas as novas contas AWS tem um Default VPC
      - É possível usar VPN para conectar com VPC
      - VPC Flow Logs permite monitorar tráfego que entra e sai do VPC
      - VPC pertence a uma conta e um Region
      - Alguns recursos AWS podem ser criados dentro de um VPC, outros não
      - É possível conectar VPCs usando Peer VPC (Para mesma conta ou outra conta)
      - VPC não é muito cobrado na certificação desenvolvedor
- - - - Cada AZ é separada fisicamente de forma isolada de outros AZ dentro de uma Region
      - O motivo é evitar que um desastre afete todos
  - - - Aos usuários deve-se dar minimas permissões para executar tarefas requeridas
      - Cuidados
        
        1 user IAM por pessoa
        
        1 role por aplicação
        
        Credenciais IAM não podem ser compartilhadas
        
        Credenciais não vão no código.
        
        Nunca use conta root
      - Root Account nunca deve ser usada ou compartilhada
    - - Policy
        
        JSON
        
        Definição das regras de permissão para as entidades
      - Hierarquia
        
        Policies
        
        Users (Normalmente atribuido a uma pessoa)
        
        Groups (Normalmente atribuido a times e função)
        
        Roles (recursos AWS)
      - É um serviço global
    - - Ativar MFA
      - Customizar URL de acesso
      - Ativar MFA como root
      - Criar Politia de senhas
      - Criar usuários
      - :checkered_flag:Primeiro acesso diagrama
  - - - Armazenamento de dados em dados virtuais (ESB)
      - Distribuição de tráfego entre as Máquinas virtuais (ELB)
      - Auto escalonamento usando auto-scaling group (ASG)
      - Network
        
        Regions (Coleção de Data Centers em um região)
        
        Uma Region possui um VPC com um endereço (ex. 10.0.0.0/16)
        
        Dentro de um VPC existem várias Availability Zone (Ex.: Data Center 1, Data Center 2)
        
        Cada Availability Zone possui várias Subnets
        (ex Subnet 1 - 10.0.1.0; Subnet 2 - 10.0.2.0)
        Esses endereços obviamente estão no range da VPC
        
        Dentro de uma Subnet você possui várias instâncias
      - Tipos de instâncias
        
        On Demand
        
        Para processos de curto prazo
        
        Paga somente pelo que usa (cobrado por segundo, depois do primeiro minuto)
        
        Tem o maior custo mas não é necessário pré-pagamento
        
        Não possui contrato pode ser terminado a qualquer momento
        
        Reserved
        
        Scheduled Reserved
        
        Para processos com janela determinada (mais barata que On Demand)
        
        Para processos de longo prazo (um ano ou mais), aplicações estáveis (ex. Banco de Dados)
        
        Até 75% de desconto comparado com On Demand
        
        Pagamento adiantado
        
        Período de reserva: 1 ou 3 anos
        
        Reserva específica para determinado tipo de instância
        
        Convertible Reserved
        
        Pode mudar a configuração da instância
        
        54% de desconto comparado com On Demand
        
        Spot
        
        Processos curtos, mais barato, pode ser terminada a qualquer momento (disputa de preços aws)
        
        Desconto de até 90% comparado com On-Demand
        
        Funciona como Leilão você usa até alguém pagar mais por ela
        
        Preço varia de acordo com oferta e demanda
        
        Você recebe um aviso de que alguém vai pagar mais pela instância e ela encerra em 2 minutos
        
        Usada por batch jobs, Big Data analysis e processos que aceitam interrupção
        
        Não deve ser usada para trabalho crítico ou banco de dados
        
        Dedicated Hosts
        
        Equipamento dedicado para usar suas instancias EC2
        
        Total controle de onde colocar as instâncias
        
        Acesso aos detalhes fisicos do equipamento
        
        Reservador por período de 3 anos
        
        Mais caro
        
        Usado para software que tem modelo de licença complexo
        
        Empresas com regras rigidas sobre onde estará o servidor
        
        reserva o equipamento inteiro, com controle de Placement
        
        Cobrado por host
        
        Dedicated
        
        Instancias rodam em equipamento dedicado
        
        Pode compartilhar instancias com outras que pertencem a mesma conta
        
        Sem controle sobre placement (pode mover pra outro hardware se for dado stop e start)
        
        Cobrado por instancia
      - Aluguel de maquina virtual (EC2)
      - Preço
        
        Varia de acordo com
        
        Region
        
        Tipo de instância
        
        OS
        
        Cobrado por segundo, mínimo 60 segundos
        
        Cobrado por armazenamento, transferência de dados, ElasticIP, load balancing ...
        
        Não é cobrado quando a instância EC2 está parada, mas os outros serviços continuam sendo cobrado
      - Instancia
        
        Tem 5 caracteristicas
        
        CPU
        
        RAM
        
        I/O
        
        Rede
        
        AWS oferece mais de 50 tipos
        
        R = especializado em RAM, C = especializado em CPU ...
        
        M = balanceado
        
        T2/T3 (burstable)
        
        CPU Tem desempenho normal
        
        Quando a instancia precisa de mais processamento creditos Burst são consumidos
        
        Quando os créditos acabam CPU volta a ter o desempenho normal
        
        Quando a carga de processamento volta ao normal, creditos Burst começam a acumular novamente
        
        T2 unlimited
        
        Possui custo extra quando os créditos acabarem
    - - :pencil2:
        
        Controla o que pode sair e entrar da instância EC2
        
        Fundamento mais importante pra solucionar problemas de rede no ambiente AWS
        
        Funciona como um firewall para instancias EC2
        
        Acessos a portas
        
        IPs permitidos
        
        Entrada e saída de dados de uma instancia EC2
        
        Caso o Security Group não permita uma requisição a sua aplicação nem saberá da tentativa pois não passará dele.
        
        Por padrão nada pode entrar (inbound) na instancia, mas tudo pode sair (outbound) da instância
        
        Cardinalidade
        
        Uma aplicação pode ter vários SecurityGroups, e um SecurityGroup pode estar em várias aplicações
        
        Escopo de ação
        
        Um Security Group só age dentro de um VPC
        
        Debug
        
        Se você recebe uma mensagem de timeout ao tentar acessar uma instancia EC2, provavelmente é o Security Group
        
        Connection refused não é Security Group, isso significa que a requisição chegou na aplicação, mas foi negado o acesso
        
        Fundamento básico de segurança AWS
      - :warning:
        
        Boa prática
        
        Ter um Security Group só pra acesso ssh
      - :star:
        
        Editar Security Group
    - - :pencil2:
        
        IPv4 ou IPv6
        
        Range de IPs privados
        
        10.0.0.0/8 [10.0.0.0-10.255.255.255]
        
        172.16.0.0/12 [172.16.0.0-172.31.255.255]
        
        192.168.0.0/16 [192.168.0.0-192.168.255.255]
        
        Quando uma instância pára o IP pública dela pode ser alterado
        
        Um Elastic IP só pode sera associado a uma instância por vez
        
        Se quiser um endereço IP fixo deve usar um Elastic IP
        
        Pode ter até 5 Elastic IP em uma conta AWS, pra ter mais tem que usar um AWS Ticket. Porém se você criar um ElasticIP e não deixar associado a nenhuma máquina você tem que pagar de qualquer forma.
        
        Por padrão instâncias EC2 são criadas com um IP privado e um público (esse último opcional)
      - :warning:
        
        Não utilize Elastic IP em produção. Demonstra baixa qualidade de arquitetura.
        
        Em produção você pode utilizar, IP aleatório com DNS ou LoadBalacing
      - :star:
        
        Atribuir Elastic IP para instancia
        
        Desassociar Elastic IP para a instancia
        
        Liberar Elastic IP
      - :movie_camera:Funcionamento de atribuição de IP
    - - :checkered_flag:Criar servidor Apache em uma instancia EC2
      - Criar instância
      - Conectar na instância
    - - Sempre atualize o sistema operacional antes de instalar novos pacotes
    - - :pencil2:
        
        Esse script é executado somente uma vez, quando a instância é criada.
        
        Utilizado no processo de boot (atualizações, instalações ...)
        
        É executado sempre como root (não precisa de sudo)
        
        Executar comandos quando uma instancia EC2 é criada
      - :star:
        
        Criar script de inicialização
- - - - Capacidade infinita
      - Muitos websites usam S3 com backbone
      - Muitos servios AWS usam S3
      - :pencil2:Objetos e Bucket
        
        Objetos (files) tem Key. Key é o caminho completo
        
        <meu_bucket>/meu_arquivo.txt
        
        <meu_bucket>/minha_pasta/outra_pasta/meu_arquivo.txt
        
        Não existe o conceito de pasta dentro do bucket, mas a interface gráfica pode
        enganar você
        
        Característica dos objetos:
        
        Tamanho máximo é 5TB
        
        Se for fazer upload de arquivo maior que 5GB deve usar “multi-part upload”
        
        Metadata (text key / value pair - system ou user metadata)
        
        Tags (Unicode key / value pair - up to 10) importante para securança
      - :pencil2:Versionamento
        
        É possível habilitar version para arquivos no S3
        
        É habilitado no nível Bucket
        
        Version: 1, 2, 3...
        
        Vantagens de utilizar version
        
        Protege contra apagamento acidental
        
        Fácil de restaurar versões anteriores
        
        Se version não estiver habilitado o arquivo terá version = “null”
      - :pencil2:Criptografia
        
        Existem 4 maneiras de criptografar objetos no S3
        
        SSE-S3: Criptografa objetos usando Key gerenciada pela AWS
        
        SSE-S3: Criptografa objetos usando Key gerenciada pela AWS
        
        Objeto é criptografado no lado Servidor
        
        Criptografia tipo AES-256
        
        Header deve ser: “x-amz-server-side-encryption”:”AES256”
        
        SSE-KMS: Key gerenciada pela Key Manager Service
        
        SSE-S3: Criptografa objetos usando Key gerenciada pela AWS KMS
        
        Vantagens de usar KMS: Controlado pelo usuário + rastreamento para auditoria
        
        Objeto Criptografado no lado servidor
        
        Header deve ser: “x-amz-server-side-encryption”:”aws:kms”
        
        SSE-C: Usuário gerencia a própria chave (key)
        
        SSE-C: Criptografa do lado servidor gerenciada pelo usuário fora do AWS
        
        S3 não armazena Encription Key fornecida pelo cliente
        
        É obrigatório o uso de HTTPS
        
        Encryption Key deve estar presente no header HTTP para todas as requisições
        
        Client Side Encryption: Criptografia no Lado Cliente
        
        Client Library como por exemplo Amazon S3 Encryption Client
        
        Cliente deve criptografar os dados antes de enviar para S3
        
        Cliente deve descriptografar dados depois de baixar do S3
        
        Cliente deve gerenciar keys and ciclo da criptografia
        
        É importante saber qual método usar para cada situação
      - :pencil2:Segurança
        
        Usuário
        
        IAM policies - Qual API é permitida para cada usuário
        
        MFA (multi factor authentication) pode ser requerido em Buckets com Versioned habilitado, para deletar objetos
        
        Signed URLs: URLs que são válidas somente por um período
        
        Recursos
        
        Bucket Policies - Regras para o bucket - Permite cross account
        
        JSON policies
        
        Resource: Buckets and Objetos
        
        Action: Allow(permitir) ou Deny(negar) API
        
        Effect: Allow / Deny
        
        Principal: Conta ou usuário para aplicar a policy
        
        Use Bucket policy para
        
        Permitir acesso público ao bucket
        
        Forçar objetos para serem criptografados ao se fazer upload
        
        Permitir acesso de outras contas (cross account)
        
        Object Access Control List (ACL) - permite controle mais granular
        
        Bucket Access Control List (ACL - Menos comun
        
        Networking
        
        Suporta VPC endpoints (acesso a recursos utilizando endereço AWS)
        
        Logging and Auditoria
        
        Acesso ao S3 pode ser armazenado em outro Bucket
        
        API calls pode ser registrados no AWS Cloud Trail
      - :pencil2:websites
        
        S3 pode ser usado para hospedar websites estático
        
        O endereço será algo do tipo:
        
        <nome-do-bucket>.s3-website-<AWS-region>.amazonaws.com
        
        <nome-do-bucket>.s3-website.<AWS-region>.amazonaws.com
        
        Se você receber o erro 403 (forbidden)(proibido). Verifique se seu Bucket está habilitado para acesso público
      - :pencil2:CORS
        
        Se for solicitar dados de outro Bucket, é necessário habilitar CORS
        
        CORS permite limitar o número de websites que podem requisitar arquivos do S3 Bucket (usado para limitar custo)
      - :pencil2:Consistency Model
        
        Ler depois de escrever para PUTS de objetos novos
        
        Assim que o objeto é escrito ele pode ser lido
        
        Isso é verdade, com exceção se fizer um GET antes para ver se o objeto existe
        
        Eventual Consistency para DELETE e PUT para objetos existentes
        
        Ao ler um objeto logo após fazer um update, pode ser retornado a versão antiga
        
        Se um objeto for deletado, pode ser que ainda fique acessível por um curto período de tempo
      - :pencil2:Perfomance
        
        Quando o número de transações por segundo é maior que 100 TPS a performance do S3 pode ser degradada
        
        Cada objeto vai para uma partição.
        É importante dividir os objetos entre as partições
        
        Era recomendado ter caracteres aleatórios na frente do
        key-name para melhor perfomance
        
        É recomendado nunca usar data como prefixo
        
        Em 17 de julho de 2018, é possível escalonar até 3500 TPS para PUT e 5500 TPS para GET para cada prefixo
        
        Sendo assim não é mais necessário criar prefixos aleatórios para melhor performance
        
        Upload para arquivos maior que 5GB, use multipart upload:
        
        Executa PUT em paralelo
        
        Maximiza a capacidade da rede
        
        Diminui o tempo para reenviar em caso de falha
        
        Use CloudFront como cache ao redor do mundo para otimizar leitura
        
        S3 Transfer Acceleration (Usa Edge Locations) - só precisa mudar o endpoint
        
        Se usar criptografia SSE-KMS, atente para o limite AWS de ~1000 download / upload por segundo