- Ryan Kroonenburg
- Perguntas são sempre baseadas em cenários
- Não pergunta "que ano o serviço X foi criado?" no exame
- Startups, plataforma para escala, serverless
- Experimentação, sem danos colaterais (apenas termina a instância e pronto)
- Aluguel de servidores era custoso e tinha um contrato
- 2003: Paper sugerindo a infraestrutura interna da Amazon, sugerindo que seja vendido como um serviço
- 2004: SQS lançado, primeiro serviço
- 2006: Lançamento oficial da AWS
- 2007: Mais de 180.000 desenvolvedores na plataforma
-
us-east-1 tem os serviços mais novos primeiros, mas também cai com mais frequência
-
Infraestrutura global AWS
- Serviços de alto nível
- Compute
- Storage
- Databases
- Network & CDN
- Security, Identity & Compliance
- --- ^ Essenciais ---
- Developer Tools
- Migration & Transfer
- Cost Management
- Management & Governance
- Machine Learning
- Desktop & app streaming
- Analytics
- Alto nível porém não são relevantes pro exame de SA:
- Robotics
- Blockchain
- Satellite
- Media Services
- Mobile
- AR & VR
- Application Integration
- Customer Engagement
- Business applications
- IOT
- Game Development
- Serviços de alto nível
-
19 regiões e 57 AZs
- AZ = Data center
- Pode ser vrios data centers, mas como eles estão próximos, são considerados 1 AZ
- Região = Área geogrfica
- Consiste de 2 ou mais AZs
-
GovCloud = Apenas para o governo, e não para empresas
-
Edge location = Endpoints usados para cache de conteúdo (CloudFront)
-
South America
-
3 AZs
-
4 Edge Locations, 2 no Rio e 2 em SP
-
Dicas para o exame
- Entender a diferença entre uma região, uma AZ e uma Edge Location
- Região é uma localização fsica que consiste de 2 ou mais AZs
- AZ é um ou mais data centers, com energia redundante, rede e conectividade, hospedados em locais diferentes
- Edge locations são endpoints usados para cachear conteúdo
- Gerenciar usuários e seu nível de acesso ao console
- Features
- Controle centralizado
- Acesso compartilhado
- Permissões granulares
- Federação de identidade (AD, SAML, LinkedIn, etc)
- MFA
- Acesso temporário a usuários e dispositivos
- Definir política de rotação de senha
- PCI DSS Compliance
- Terminologia
- Usuários: usuários finais do console/cli
- Grupos: Conjunto de usuários com herança de permissão
- Policies: Documento JSON descrevendo as permissões do user/group/role
- Roles: São "usuários" atachados a recursos da AWS
- É possível criar um alias da conta para personalizar o link de login no console
- IAM não possui regiões
- Root account é a primeira conta que foi criada no console. Possui acesso admin total (god mode)
- Novos usuários não possuem permissões quando criados, você tem que atachar
- Access key não é a mesma coisa que login e senha. Não dá pra usar a access key pra logar no console
- Só dá pra ver a senha gerada do usuário e o secret access key uma única vez
- Sempre habilitar MFA
- Dá pra criar e customizar políticas de rotação de senha
- S3 é um lugar seguro para enviar arquivos/objetos
- Arquivos podem ser de 0 bytes até 5TB
- Storage ilimitado
- Arquivos armazenados em buckets
- Nome dos buckets devem ser únicos globalmente
- Quando você envia um arquivo para o S3, você recebe um status code HTTP 200 se der certo
- É possível ativar MFA Delete, pra proteger os arquivos
- Não é possível instalar um sistema operacional nele
- Objetos consistem de:
- Chave (nome do objeto)
- Valor (sequência de bytes, dados do obj)
- ID da versão
- Metadados
- Subrecursos (ACLs e Torrent)
- Modelo de consistência de dados
- Read after Write para novos objetos
- Leitura imediata
- Eventual consistency para PUTs de edição e DELETEs
- Pode levar um tempo p/ propagar
- Talvez você veja a versão antiga imediatamente, e a versão nova depois de alguns segundos
- Read after Write para novos objetos
- SLAs
- Construído para 99.99% de disponibilidade
- AWS garante 99.9% de disponibilidade
- AWS garante 99.99999999999% de durabilidade (onze 9s)
- Tiers
- S3 Standard
- 99.99% disponibilidade
- 99.99999999999% durabilidade
- Redundante, multi AZ
- IA (Infrequent Access)
- Custo menor que o S3
- Taxa para obter os dados
- Para dados que são acessados com pouca frequência, mas você precisa deles imediatamente
- One Zone - IA (RRS - Reduced Redundancy Storage)
- Menor custo, sem multi AZ
- Intelligent tiering
- Analisa frequência de uso, escolhe o tier automaticamente
- Sem degradar performance ou gerar overhead operacional
- Glacier
- Arquivar dados (ex. por causa de leis federais)
- Muito barato
- Tempo de recuperação é configurável, de minutos a horas
- Glacier Deep Archive
- Tempo de recuperação de 12 horas
- Menor custo
- S3 Standard
- First byte latency = milisegundos, a não ser pro Glacier
- Cobrança do S3
- Bytes armazenados
- Número de requisições (PUTs é mais caro)
- Storage Management Pricing (tiers diferentes)
- Transferência de dados
- Aceleração de transferência
- Replicação entre regiões
- **Ler as FAQs do S3 antes de fazer o exame
- Bucket tem uma região, mas o console do S3 é "global"
- Não é possível tornar objetos públicos sem antes permitir que eles sejam a nível de bucket
- Controle de acesso aos buckets/objetos pode ser feito tanto via Bucket ACL quanto por Bucket Policies
- Encryption in Transit
- SSL / TLS
- Encryption at Rest (server side)
- S3 Managed Keys (SSE-S3): AWS cuida das chaves de criptografia
- Pelo console: AWS cria uma chave AES-256 pra você
- Key Management Service (SSE-KMS) : Você e a AWS cuidam das chaves
- Customer Provided Keys (SSE-C): Você cuida das chaves
- S3 Managed Keys (SSE-S3): AWS cuida das chaves de criptografia
- Client side encryption: Você criptografa antes de subir
- Armazena todas as versões de um objeto, incluindo deletes
- Ótimo como ferramenta de backup
- Depois de habilitado, não pode ser desabilitado, apenas suspenso
- Se integra bem com regras de lifecycle
- MFA delete para + segurança
- Novas versões não herdam permissões, é como se fosse um novo arquivo
- Automatizar mover os objetos para tiers de armazenamento diferentes
- Regras de lifecycle podem ser aplicadas por prefixo ou tags também
- Dá pra aplicar pros arquivos novos e pros arquivos existentes, separadamente
- Replicar objetos em buckets em regiões diferentes
- Requer versioning ativado nos buckets de destino e origem
- Não envia os objetos que já estavam no bucket
- Não replica deletes
- Usa a rede do CloudFront pra tratar uploads (PUTs) também, tornando o upload mais rápido pois tem um endpoint mais perto de você
- https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html
- CDN, rede de entrega de conteúdo com servidores distribuídos mundialmente
- Edge location: Lugar onde o conteúdo será cacheado. Diferente de uma região ou AZ
- Origin: Origem dos arquivos distribuídos pela CDN
- Pode ser bucket S3, instancia EC2, ELB, Route53, etc
- Distribution: Nome dado pra CDN, que é uma coleção de edge locations
- Entrega conteúdo dinâmico, estático, streaming e interativo
- Distribuições
- Web distribution
- RTMP: Streaming
- Edge locations não são READ ONLY (tem o Transfer Acceleration)
- Objetos são cacheados pela duração do TTL (segundos)
- Dá pra invalidar o cache, mas é cobrado
- Dá pra restringir acesso (usando Signed URLs ou Cookies)
- Solução para transferência de dados a nível de petabytes para dentro e fora da AWS
- Tamanho de 50 ou 80TB
- Design pra proteger os dados, tudo criptografado, depois que termina a transferência a AWS formata a aplicação do Snowball
- Importar e exportar arquivos do/para S3
- Snowball Edge: 100TB com capacidade de computação. Local
- Snowmobile: Caminhão para transferência de dados a nível de exabytes
- File Gateway
- Arquivos armazenados no bucket, e acessados via NFS
- Volume Gateway
- Backup assíncrono dos HDs, protocolo iSCSI
- Snapshots são incrementais e comprimidos
- Stored Volumes: Dados primários locais, backup assíncrono pra AWS (S3)
- Cached Volumes: Dados primários no S3, dados mais frequentes no on-premises, mantendo baixa latência
- Tape Gateway
- Arquivar fitas no S3
- Virtual Tape Library é uma interface que se integra com aplicações de backup em fitas, armazenando os dados no tape gateway
- Capacidade de computação redimensionável em nuvem
- Scale up e down
- Whitepaper sobre AWS pricing: https://d0.awsstatic.com/whitepapers/aws_pricing_overview.pdf
- Filosofia da AWS: Pague conforme o uso, pague menos se usar mais, pague menos ainda se reservar capacidade
- Modelos de precificação:
- On demand: Pagar uma taxa fixa por hora/minutos/segundos, sem compromisso
- Baixo custo e flexibilidade, sem pagamento adiantado ou fidelidade
- Aplicações com carga de trabalho curtas, variáveis ou imprevisíveis, que não podem ser paradas
- Aplicações sendo desenvolvidas e testadas na AWS pela primeira vez
- Reserved: Reserva de capacidade, com um desconto significante na cobrança por hora. 1 ou 3 anos
- Aplicações com estado estável ou uso previsível
- Aplicações que precisam de uma capacidade reservada
- Usuários podem fazer pagamentos adiantados pra diminuir mais ainda o preço
- Não pode trocar de região dpeois que reservou
- Precificação:
- Standard Reserved Instances: 75% de desconto, quanto mais pagar ou mais longo for o contrato, maior o desconto também
- Convertible reserved instances: até 54% de desconto, permitindo trocar a capacidade da RI desde que o resultado da troca seja de valor igual ou maior
- Scheduled reserved instances: Lançam em uma janela de tempo que reservou
- Spot: Capacidade não utilizada, preço flutua e você "dá um lance" no preço que quer
- Aplicações que possuem início e fim flexível
- Aplicações que só servem com custo computacional muito baixo
- Usuários com necessidades urgentes para grandes quantidades de capacidade adicional
- Dedicated hosts: Servidores físicos dedicados para utilização. Dá pra utilizar licenças de software que são vinculadas ao servidor, ou cumprir requisitos de compliance
- Requisitos regulamentrios que não permitem virtualização multi-tenante
- Licenças que não permitem multi-tenancy
- Podem ser comprados on-demand (por hora)
- Podem ser reservados com até 70% de desconto
- On demand: Pagar uma taxa fixa por hora/minutos/segundos, sem compromisso
- Se a AWS terminar uma spot, é cobrado pela hora parcialmente. Se o usuário terminar a spot, é cobrado pela hora cheia.
- Termination protection off por padrão
- Instância com ec2, remove o disco EBS quando terminar a instância por padrão
- alterações no SG são aplicadas imediatamente
- SGs são stateful - quando cria o inbound, automaticamente cria o outbound também, e vice versa
- Network ACL (vpc) é stateless, tem que criar os 2
- não é possível bloquear portas no SG, apenas permitir. Policy é drop por default. NACL permite bloquear tho
- todo tráfego outbound é bloqueado por default
- não dá pra bloquear IP específicos, tem que usar NACL
- cada volume é replicado nas suas AZs para garantir HA
- 5 tipos de volumes
-
GP SSD - gp2
- maioria dos workloads
- bom custo benefício
- discos a partir de 1gb
- até 16k iops
-
PIOPS SSD - io1
- geralmente pra banco de dados, mission critical
- até 64k iops
-
HDD otimizado para vazão (throughput) - tp1
- Big data e data lake
- mínimo de 500gb
-
Cold HDD - st1
- dados menos freq. Acessados
- file servers
- menor custo
- mínimo de 500mb
- quando por algum motivo glacier não rola
-
magnetic HDD - Standard
- aplicações que dados são infrequentemente acessados
- mínimo de 1gb
-
- O volume SEMPRE fica na mesma AZ que a instância está
- Mover volume de AZ ou região = Criar snapshot e AMI
- Volumes adicionais não vem com "delete on termination" ativado por default
- Snapshots existem no S3
- Snapshots são incrementais
- Pra fazer snap de root devices, parar a instância pra garantir a consistência
- Dá pra criar AMIs de volumes e snapshots
- Dá pra trocar os tipos e tamanhos de volumes sem downtime
- Volumes Instance Store => Ephemeral storage
- Volumes não podem ser parados, se desligados perdem todos os dados
- Reboot é ok, não perde os dados
- Por padrão, os volumes root podem ser deletados, mas com EBS store você pode pedir pra AWS manter o volume
- Antes não dava pra encriptar o root quando lançava, agora dá
- Para encriptar depois que lança a instância sem encriptar, tem que criar um snapshot, fazer uma cópia desse snap com criptografia ativada, criar uma AMI e lançar uma instância
- Não dá pra pegar um snapshot criptografado e lançar ele sem criptografia
- Dá pra compartilhar os snapshots, mas apenas se eles não estiverem encriptados
- Dá pra compartilhar com outras contas ou tornar eles públicos
- Monitorar performance
- Monitora a maioria da AWS e as aplicações que rodam lá
- 5 minutos default, detailed monitoring para 1 minuto
- Criar alarmes
- CW pode monitorar coisas como:
- Compute
- EC2 instances
- ASG
- ELB
- Route53 Health Checks
- Storage & CDN
- EBS volumes
- Storage Gateways
- CloudFront
- Compute
- Métricas a nível de host - questão importante, cai bastante
- CPU
- Rede
- Disco
- Status check
- CloudTrail é CCTV, grava as atividades do console e chamadas de API
- Audit
- Std. monitoring = 5 min, detailed = 1 min
- Dá pra criar alarmes que mandam e-mail ou qualquer outra coisa do SNS
- Dá pra criar dashboards por região ou globais
- Logs: Enviar logs do servidor e da aplicação, fazer análise via Insights, agregação
- Events: Eventos de sistemas quase em tempo real, descrevem mudanças em recursos da AWS, permitem responder a mudanças de estados nos recursos AWS
- Usuario com Programmatic access para acessar o CLI
- Não é uma boa prática deixar as credenciais dentro da EC2, e sim no role do IAM
- Roles são mais seguros que usar as chaves na mão
- Roles são mais fáceis de gerenciar
- Roles podem ser atachados em uma instãncia mesmo depois que ela foi criada
- Roles são universais, pode usar eles em qqr região
- Script bash executado quando a instãncia roda, no user data
- Informações sobre a instância de dentro dela
- curl http://169.254.169.254/latest/meta-data
- Compartilhar um volume entre várias instâncias
- NFS da Amazon
- Capacidade elástica
- Suporte para NFSv4
- Paga apenas pela storage
- Escalar a petabytes
- Milhares de conexões concorrentes
- Multi-AZ
- Consistência = Read after write = Leitura imediata
- Forma de colocar as instâncias EC2
- Clustered PLacement Group
- Grupo de instâncias em uma AZ
- Recomendado para aplicações que precisam de baixa latência, alto TP de rede, ou ambos
- Deixar as instâncias bem "perto" uma das outras
- Apenas algumas instâncias podem ser lançadas em clustered
- Spread placement group
- Hardware distintos, racks separados, etc
- Instâncias críticas individuais
- Maior tolerância a falhas (se falhar falha apenas 1)
- Aplicações que tem um pequeno número de instâncias que deve ser mantido separado de cada
- Partition placement group
- Múltiplas instâncias em uma partição
- Divide os grupos de EC2 em partições
- Cada partição em um rack
- Clustered não pode usar multi-az, spread e partitioned podem
- Nome deve ser único na conta AWS
- Apenas alguns tipos de instâncias podem ser lançados - Compute, GPU, Memory, Storage
- Em clusters, é melhor deixar as instâncias homogêneas (iguais)
- Não dá pra mesclar placement groups
- Não dá pra mover uma instância existente, mas dá pra criar uma AMI dela
- Pricing models para o EC2:
- On demand: pague por hora, sem fidelidade
- Reserved: reserva para 1 ou 3 anos, desconto
- Spot: Dar lance no preço que você quer pagar
- Dedicated hosts: Servidores fsicos dedicados, bom p/ licenças de software
- Se a AWS termina uma spot, você não é cobrado pela hora parcial, mas se você terminar a isntância ser cobrado pela hora inteira
- Termination protection off por padrão
- Padrão é terminar o volume root EBS, os outros persistir
- Security group
- Tráfego inbound block default
- Trfego outbound allow default
- Mudanças imediatas
- Relação SG x instâncias é M:N
- Stateful (abre inbound e outbound)
- Não pode bloquear IPs específicos
- Allow rules apenas, nenhuma deny rule
- EBS
- Virtual HD
- Snapshots ficam no S3, são cópias de volumes incrementais
- Primeira snapshot pode demorar um pouco
- Parar instância antes de fazer snapshot do root volume
- Dá pra criar AMI de volumes e snapshots
- Dá pra trocar o tamanho dos volumes EBS dinamicamente
- Volume sempre na mesma AZ da instância
- Migração AZ: Snapshot -> AMI -> Lançar instância
- Migração Região: Snapshot -> AMI -> Copiar AMI p/ nova região -> Lançar instância
- Snapshots de volumes encriptados são encriptados autom.
- Volumes restaurados de snaps encrp. são encrp. autom.
- Compartilhar snaps apenas se não estiverem encrp.
- Snaps podem ser compartilhadas ou tornadas públicas
- Dá pra encriptar root device
- Encriptar volume rodando que não foi encriptado:
- Criar snap -> Criar cópia snap encriptada -> AMI -> Lançar instância
- Instance Store = Ephemeral Storage
- Se parar, perde os dados
- Delete on termination
- Cloudwatch
- Monitorar performance
- Maior parte da AWS e as aplicações rodando na AWS
- 5 minutos default, 1 minuto detailed
- Alarmes
- Dashboards, Alarmes, Events, Logs
- CLI
- Configurar acesso programático no IAM
- Não caem comandos no teste
- Roles
- Credenciais para instâncias EC2
- Universais
- Bootstrap scripts: no boot da instância, automatizar inst. software
- Metadata: INformações sobre uma instância - 169.254.169.254/latest/meta-data/
- EFS
- NFSv4
- Paga pelo storage
- Escala para petabytes
- Milhares de conexões concorrentes
- Multi-AZ
- Read after write
- Placement group
- Clustered
- Instâncias no mesmo rack
- Baixa latência, alto TP de rede
- Se der pau no rack fudeu
- Recomendação é que as instâncias em um cluster sejam homogêneas
- Spread
- Instâncias isoladas
- Maior tolerância a falhas
- Máximo 7 instâncias por AZ
- Partitioned
- Grupo de instâncias no mesmo rack
- Multi AZ apenas spread e partitioned
- Nome deve ser único na conta
- Apenas alguns tipos podem ser usados (Compute, GPU, Memória, Storage)
- Mover placement group = Apenas com AMI
- Clustered
- Relational DBs on AWS:
- SQL Server
- Oracle
- MySQL / MariaDB
- Postgres
- Aurora
- RDS tem duas features chaves:
- Multi AZ: Disaster recovery
- Base primária e secundária, em AZs diferentes
- Se a primária cai, a AWS aponta o DNS pra base secundária
- Read replicas: Performance
- Replica todos os writes pra uma read replica
- Se a primary cai, teria que criar um novo endpoint RDS pra read replica
- Apontar metade do tráfego para uma read réplica, metade para outro
- Pode ter até 5 read replicas
- Multi AZ: Disaster recovery
- Non relational databases:
- Collection = Table
- Document = Row
- Key value pairs = Columns
- Data Warehouse
- Business intelligence
- Very large and complex data sets
- Queries on data
- Usar bases diferentes para transação vs analytics
- Redshift = Solução da AWS
- ElastiCache
- Cache em memória, rápido
- DB sobrecarregado, ElastiCache é uma solução
- Memcached e Redis
- Cache queries frequentes idênticas
- Bases de dados na AWS - RDS = OLTP - DynamoDB = NoSQL - RedShift = OLAP - ElastiCache
- Dá pra passar um ID de SG no lugar do IP na hora de liberar uma porta no SG
- RDS roda em VMs, mas não temos acessos para logar nesses OSs
- Patching do SO é responsabilidade da AWS - RDS não é Serverless (apesar de que o Aurora Serverless é)
- 2 tipos de backups
- Automated backups
- Recuperar DB a qualquer ponto dentro de um "período de retenção"
- Período entre 1 e 35 dias
- Snapshot diário e log de transação, AWS aplica a snapshot mais recente e depois os logs de transação daquele dia
- Dá pra especificar os minutos e segundos do restore
- Enabled por default
- Armazenado no S3
- Espaço grátis igual ao tamanho do banco
- Se tem um RDS de 10GB, você ganha 10GB de storage
- Backups feitos em uma janela - Snapshots
- Iniciados pelo usuário
- Ficam mesmo depois que deleta a instância
- Restore (Automtico ou manual) gera um novo endpoint
- Encryption at rest - AWS KMS
- Quando a instância está criptografada, backups e snapshots também serão
- Multi AZ
- Base stand by, replicação automtica
- Em caso de manutenção, falha na instância ou na AZ, failover para o standby - Apenas recuperação de disastres
- Disponvel para: SQL Server, MySQL, Oracle, PostgreSQL e MariaDB
- Dá pra forçar failover rebootando a instância
- Read replicas
- Aumentar performance
- Backups devem estar ativados
- Escala horizontal
- Arquitetar aplicação para as instâncias usarem as read replicas para queries read-only
- Read-heavy workloads
- Disponível para: MySQL, Oracle, PostgreSQL, MariaDB, Aurora
- Usados para escala - Podem ser multi AZ
- Deve ter automatic backups ligados para subir uma read replica
- Pode ter até 5 read replicas de uma base
- Pode ter read replicas de read replicas (mas latência vira um problema)
- Cada read replica tem um DNS único - Read replicas podem ser promovidas para bases normais, mas isso quebra a replicação - Read replicas podem ficar em regiões diferentes
- NoSQL
- Consistência, latência de 0-9ms, em qualquer escala
- Gerenciado, suporta documentos e key-value pairs
- Armazenado em SSD
- Armazenado em 3 geo distinct data centers
- Eventual consistent reads
- Consistência em todas as cópias geralmente demora 1 segundo
- Default
- Ler dados escritos alguns segundos depois
- Strongly consistent reads
- Consistência demora menos de 1 segundo
- Ler dados escritos milisegundos depois
- Serviço de data warehouse gerenciado
- Single node (160Gb)
- Multi node
- Leader node (gerencia conexões e recebe queries)
- Compute node (armazena e executa queries e cálculos). Até 128 nodes.
- Compressão baseada em colunas, melhor desempenho pois todos os dados são do mesmo tipo
- Não requer índices ou views materializadas, então usa menos espaço
- Sampleia os dados sendo inseridos e escolhe a compressão mais adequada
- Massively parallel processing (MPP)
- Distribui dados e carga das queries em todos os nodes
- Backups
- Ativados por default, 1 dia de retenção mas pode ir até 35 dias
- Sempre tenta manter 3 cópias dos dados - Original e réplica nos nodes, um backup no S3
- Replica snapshots no S3 em outra região para DR
- Pricing
- Horas de compute node
- 1 unit / node / hour
- 3 nodes por 1 mês = 2.160 horas
- Não tem cobrança pelo leader node
- Backups
- Transferência de dados (dentro de uma VPC, não fora dela?)
- Segurança
- Encryption in transit c/ SSL
- Encryption at rest c/ AES-256
- Redshift cuida do key management
- Gerenciar suas próprias chaves com HSM ou AWS KMS
- Availability:
- 1 az
- Dà pra restaurar snapshots em outras AZs
- Banco relacional compatvel com o MySQL e Postgres
- Até 5x melhor performance que o MySQL e 3x melhor que o Postgres
- Começa com 10GB, escala em incrementos de 10GB
- Recursos podem escalar até 32vCPUs e 244GB de memria - 2 cópias de dados são mantidas em cada AZ, com no mínimo 3 AZs, ou seja, 6 cópias dos dados
- Transparentemente tratar a perda de
- até 2 cópias de dados sem afetar writes
- até 3 cópias de dados sem afetar reads
- Self healing (discos se escaneiam e reparam erros) - 2 tipos de réplicas disponveis - Aurora replicas (atualmente 15) e MySQL read replicas (atualmente 5)*
- Backups
- Sempre ativos, não impactam a performance
- Pode tirar snaps, também não impacta performance - Compartilhar snaps com outras contas
- Converter MySQL pra Aurora
- Criar aurora read replica
- Promover read replica
-
Serviço que provisiona um cache em memória na nuvem - Melhora a performance de aplicações web criando cache de queries lentas
-
Memcached
- Simples
- Escala horizontal
- Multithread
-
Redis
- Tipos de dados avançados
- Organizar dados
- Pub/sub - Multi-AZ, persistence, backup e restore
-
Se você precisa de multi az ou backups => Redis
-
Se você precisa de escala horizontal => Memcached
-
É possível reservar instâncias RDS
- Route 53 = DNS fica na porta 53
- DNS = Lista telefônica
- IPV4 = 32 bits, estão acabando os endereços
- IPv6 = 128 bits
- TLDs são controlados pela IANA em uma zona raíz
- ICANN garante que os domínios sejam únicos
- Domain registrar é uma autoridade que pode fornecer domain names
- Start of Authority Record (SoA)
- Servidor que forneceu os dados
- Administrador da zona
- Versão do data file
- TTL default
- NS = Name Server Records -> USados pelos TLDs pra direcionar tráfego p/ content DNS server que contém os registros uatoritativos do DNS
- TTL: Tempo que o DNS fica cacheado, quanto menor, mais rápido as mudanças se propagam
- Default TTL = 48 horas
- Tipos de records:
- "A": Address, aponta para um endereço IP
- CNAME: Canonical Name, resolve um domínio para outro
- Não pode ser usado para os domínios raízes, tem que ser A ou alias
- Zone apex record
- da pra criar um bucket com redirect
- Exam tips
- ELBs não possuem endereços IP pré definidos, sempre resolvem pelo DNS
- Diferença entre um alias record e CNAME
- Sempre escolha um alias record em vez do CNAME
- Estudar os tipos comuns de DNS
- SOA
- NS
- A
- CNAME
- MX
- PTR
- TXT
- Alias: Mapeam recursos na sua zona hospedada para ELBs, CloudFront ou buckets S3
- Dà pra comprar domains com a AWS
- Pode levar 3 dias pra registrar
-
Simple Routing
- Um registro com vários endereços IPs. Route 53 retorna para o usuário um registro aleatoriamente
-
Weighted Routing
- Roteamento baseado em pesos. ex 20% pra um IP, 80% pra outro
- Set ID é o nome
- Associate with Health Checks = Remove do Route 53 até que os health checks voltem a ficar OK
- Health checks criados no Route53 mesmo
-
Latency-based routing
- Menor latência de rede pro usuário que está solicitando (a que vai responder mais rápido)
- Verifica com base na região da AWS que você escolher
-
Failover routing
- active / passive, disaster recovery
- route53 faz um health check na url
-
Geolocation routing
- baseado Na região geográfica
- enviar para um fleet de instâncias configuradas praquela região (moeda, linguagem, etc)
- em cima de continentes ou países
-
Geoproximity Routing (traffic flow only)
- roteamento em cima da região geográfica dos usuários, bem como em cima dos recursos
- rotear mais ou menos especificando um bias
- bias aumenta ou diminui o tamanho da zona geográfica
- deve ser usado em conjunto com o traffic flow
-
Multivalue answer routing
- permite inputar múltiplos valores porém pra cada valor da pra colocar um healthcheck
- Elb não tem IP, e sim DNS
- diferença entre aliás record e cname
- aliás record = lists Telefonica, cname = alguem dizendo o próprio nome
- podendo escolher, pegar sempre o aliás record
- wsthdar tipos de dns
- estudar tipos de routing
- da pra criar health checks Para record sets
- se o health Check falhar o route 53 remove o recordset até que ele volte a funcionar
- da pra receber notificações sns quando o health.check falhar
- tem que saber subir uma VPC de memória
- VPc e tipo um datacenter privado na cloud
- Arquitetura da VPC
- Vpc fica localizada em uma região
- Entrada é pelo Internet gateway (público) ou virtual private gateway (privado)
- Esses dois passam pelo router
- a requisição passa pelo route table e pelo network acl, dependendo das regras ela continua pra subnet
- na subnet ela passa pelo security group e acessa a instância
- da pra setar um CIDR range pra Vpc inteira, e um pra cada subnet
- faixas de IP privado iana
- 10.0.0.0/8 - vai até 10.255.255.255
- 172.16.0.0/12 - vai até 172.31.255.255
- 192.168.0.0/16 - vai até 192.168.0.0
- aws não permite criar Vpc com faixa /8, apenas /16
- /28 é a menor subnet que dá pra ter na aws
- CIDR.xyz
- vpc peering - conectar uma vpc à outra usando uma rota de rede direta
- peer entre vpcs de uma conta, entre regiões e entre contas também
- peering e configuração de estrela, uma vpc central e outras 4 pontas
- sem peering transitivo
- peering tem que ser direto com a vpc, não dá pra usar outra vpc como "intermediário"
- Não dá pra fazer peering entre regiões
- 1 subnet = 1 AZ diferente
- atribuir public ip: modificaf a vpc na opção modify auto assign public ip
- apenas um igw atacado em uma vpc
- main route table ê usada por padrão em todas as subnets que não estão vinculadas a uma
- boa prática é deixar a main privada, e criar uma pública caso necessário
- liberar acesso pra Internet: criar uma rota para 0.0.0.0/0 e associar ela ao IGW
- ::/ para ipv6, ligado no igw
- associar subnet com a route table
- nomes us-east-1a são aleatórios
- subnets e igw não são criados por padrão quando cria a vpc
- aws sempre reserva 5 endrcs IP por subnet
- 1 IGW por vpc
- security groups são vinculados a vpcs
- deixar a pem na instância não é uma boa prática, melhor usar bastion hosts
- se a instância estiver em uma subn priv sem rota pra Internet ela não vai conseguir instalar pkgs
- resolver isao: Nat instances ou NAT gateway
- Nat instance: uma instância capaz de fazer NAT
- Nat gateway: serviço Nat altamente disponível e escalável
- tem uma ami pra Nat instance, no jeito já
- pra nat instance funcionar, tem que desabilitar source/destination checks
- por padrão as EC2 verificam se o pacote é rpa elas ou não, e descartam se não é.
- também tem que criar uma rota na route table padrão, pra encaminhar todo o tráfego pra Internet (0.0.0.0/0) pra nat instance
- na route table, o estado "blackhole" indica que o recurso não existe mais
- Nat gateway é uma solução altamente disponível e escalável, serviço Nat gerenciado. Caro pra carai tbm
- Exam tips
- NAT tem que estar na subnet pública
- Nat instance pode ser um bottleneck, aumentar o tamanho da instância caso esteja gargalando
- Da pra deixar Nat instance HA usando AZs e script pra automatizar o failover
- Nat instances estão sempre atrás de um security group
- Nat gateway é redundante dentro da AZ apenas
- não é associado a security groups
- totalmente gerenciado e escalável
- automaticamente recebe um elastic ip
- Para uma arquitetura com subnets em múltiplas AZs, deve ser arquitetada uma infra com um Nat gateway em cada subnet pública, pois caso dê pau em uma AZ, os NAT instances/gateways dela não vão funcionar, e todas as instâncias que usam eles vão parar também
- VPC vem com uma route table default, que permite tudo inbount e outbout
- AWS recomenda regras em incrementos de 100
- Se precisar colocar uma regra antes ou depois, é só coloca no 99 por exemplo
- Deny all by default
- Regras são avaliadas em ordem, então se tiver um ALLOW antes de um DENY, o DENY não vai funcionar
- Uma subnet só pode se associar com 1 route table, mas uma route table pode ser associada com N subnets
- Regras são aplicadas imediatamente
- Agem antes dos security groups
- Bloqueio de endereço IP feito no NACL, não nos security groups
- Stateless: regras de inbound estão sujeitas a regras de outbound
- Load balancer precisa estar em duas subnets, caso contrário não funciona
- Logar tráfego IP que passa pela VPC
- Logs ficam disponíveis no CloudWatch
- 3 níveis
- VPC
- Subnet
- Interface (ENI)
- Filtros para logar tráfego aceito e rejeitado
- Destination: CloudWatch ou S3
- Destination log group: Criar um log group no CloudWatch
- IAM Role
- Não dá pra ativar flow logs para VPC peering, a não ser que a VPC peer está em sua conta
- Não dá pra taggear um flow log
- Não dá pra editar depois que cria
- Não é todo tráfego que é monitorado, exemplos que não são:
- Tráfego gerado pelas instâncias quando elas batem no DNS da AWS
- Se vc usa um DNS próprio, o tráfego àquele servidor é logado
- Tráfego gerado por uma instância Windows para fazer a ativação da licensa
- Tráfego para 169.254.169.254 para metadados
- Tráfego DHCP
- Tráfego para o endereço IP reservado para o router padrão da VPC
- Tráfego gerado pelas instâncias quando elas batem no DNS da AWS
- Máquina configurada para aguentar ataques
- DMZ = Public subnet
- NAT é usado pra fornecer acesso à internet para EC2 em private subnets
- Bastion é usado para administrar instâncias EC2, aka jump boxes
- Não dá pra usar NAT Gateway como bastion host (mas NAT instance dá)
- Conexão dedicada e privada do on premises para a AWS
- Reduzir custos de network, aumentar TP de banda, fornecer uma experiência mais consistente
- Útil para workloads com alto TP, ou se é necessrio uma conexão estável e confiável
- Caso a VPN fique caindo pelo alto workload
- Conexão privada a alguns serviços AWS
- Interface endpoint = ENI com um endereço IP privado
- Atacha a ENI à EC2, e tada!
- Gateway Endpoints
- Parece com o Nat Gateway
- S3 e Dynamo
- Criados no console, tela de Endpoints > Create endpoint
- Precisa especificar a região
- Escalável
- Application Load Balancers
- Inteligentes
- HTTP e HTTPS apenas
- Camada 7
- Roteamento avançado
- Consegue enxergar configurações do usuário (ex. locale, moeda, etc)
- Network Load Balancers
- TCP
- Performance extrema
- Camada 4
- Caro
- Milhões de reqs/s, latencia ultra baixa
- Classic Load Balancers
- Legacy
- HTTP, HTTPS e TCP
- Features específicas da camada 7, como x-forwarded-for e sticky sessions
- Mais barato
- Erro 504
- Problema na aplicação e não no load balancer
- X-Forwarded-For: cabeçalho que indica o IP do usuário que fez a requisição
- Por padrão a requisição vai pra aplicação com o IP interno do LB, e vai ficar esse IP nos logs
- Instâncias monitoradas pelo ELB estarão em: InService ou OutOfService
- Load balancers sempre tem um DNS name, nunca um IP
- A não ser no caso de Network LBs
- Provavelmente 10 questões sobre LBs, ler as FAQs
- Sticky sessions permitem conectar uma sessão de usuário a uma instância específica
- Nos application load balancers, a sticky session se aplica a nivel de target group
- Cross zone load balancing: Um único LB pode enviar tráfego para mais de uma AZ
- Path patterns (ALB)
- Listener com regras baseadas no caminho da URL para fazer o roteamento
- Launch configuration
- Define AMI, EBS, configurações das instâncias, key pair, etc
- AutoScaling Group
- Define rede e subnet, tamanho do grupo
- Configurar scaling policies, notificações
- Infra como código
- Quick Start são templates construídos por solutions architects
- Usuários que não tem experiência com AWS, apenas querem subir um site
- Provisiona ASGs, etc
- Message queue system - Desacoplar componentes da aplicação para que eles rodem independentemente
- Até 256KB de texto
- Pegar as mensagens via SQS API
- Tipos de filas
- Standard (default)
- quase-ilimitadas transações por segundo
- Garantem que a mensagem seja entregue pelo menos uma vez
- Uma mensagem pode ser entregue fora de ordem
- Uma mensagem pode ser entregue mais de uma vez
- FIFO
- Ordenada
- Mensagens são entregues apenas uma vez
- Suporte para múltiplos grupos de mensagens ordenadas em uma fila
- 300 transações por segundo
- O resto é igual ao standard
- Standard (default)
- Sempre pull based (instâncias "puxam" as mensagens da fila), push based = SNS
- Mensagens podem ficar na fila de 1 minuto a 14 dias, retenção padrão é de 4 dias
- Visibility Time Out
- Depois que o reader pega a mensagem, ela fica "invisível"
- Se o reader não deletar a mensagem dentro do timeout (Ex. instância morreu), a mensagem fica visível de novo e outro reader vai processar ela
- Isso pode fazer com que a mesma mensagem seja entregue duas vezes
- Timeout máximo = 12 horas
- SQS garante que as mensagens vão ser processadas pelo menos 1x
- Long polling = esperar até que uma mensagem chegue na fila (ou dê timeout), economiza dinheiros
- Web service que facilita coordenar interações entre sistemas e humanos
- Use cases: processamento de mídia, processos de negócios, pipelines analíticas. Case da AWS, que usa o SWF pra coordenar venda de livros e entrega nos armazéns
- Geralmente sempre que tiver "interação humana" na questão será SWF. Humanos não conseguem ficar chamando uma fila no SQS
- Execuções de workflow podem durar até 1 ano
- API orientada a tarefas
- Uma tarefa é atribuída apenas uma vez, e nunca é duplicada
- SWF acompanha todas as tarefas e eventos em uma aplicação
- SWF actors
- Workflow starters: Inicia um workflow. Aplicação. E-commerce criando um pedido
- Deciders: Controlam o fluxo de tarefas na execução. Se algo falhar, eles decidem o que fazer
- Activity Workers: Levam as tarefas de atividade
- Serviço de notificações de aplicações para subscribers ou outras aplicações
- Notificações via e-mail ou SMS para o SQS, ou para qualquer endpoint HTTP
- Agrupar recipientes usando tópicos
- Um tópico pode ser enviado para vários tipos de endpoints
- Redundâncias entre multiplas AZs para evitar perder mensagens
- Entrega instantânea, sem polling
- SNS vs SQS: SNS = Push, SQS = Poll (pull)
- Transcoding de mídia em nuvem
- Converter formatos de arquivos
- Presets para outputs comuns
- Pague por minutos transcodados e a resolução
- "Porta da frente" para serviços de back-end (lambdas, ec2, etc)
- Pode escrever no DynamoDB
- Baixo custo e escala
- Rastrear e controlar uso pela API key
- Throttling de requisições
- Versionamento da API
- Cache de respostas baseado em um TTL
- Same origin policy
- Scripts podem conversar entre si apenas se eles tiverem o mesmo domínio
- Postman e cURL ignoram
- Evitar ataques XSS
- CORS: relaxar a same-origin policy
- Origin policy cannot be read at the remote resource -> Ativar CORS no API Gateway
- Dados de streaming: dados gerados continuamente por milhares de data sources, que geralmente enviam simultaneamente e em pequenos tamanhos (kbs)
- Exemplos:
- Compras de lojas online (ID da transação, uuid do item, etc)
- Precos de ações
- Game data (conforme a pessoa joga)
- Redes sociais (Twitter)
- Dados geoespaciais (Uber)
- Sensores IoT
- Kinesis = Lugar para enviar seus dados de streaming
- Facilita carregar e analisar dados
- 3 tipos de Kinesis
- Kinesis Streams
- Data producers fazem stream dos dados para o Kinesis
- Enviam esses dados para o Kinesis Streams
- Retenção padrão de 24 horas, mas pode ir até 7 dias
- Dados são armazenados em "Shards" (tipo filas/topics)
- Consumers (EC2) podem analisar os dados dentro desses shards
- Depois de analisar, eles podem armazenar esses dados em outro lugar: S3, Dynamo, EMR, Redshift - Se tiver "shards" na questão, deve ser do Kinesis Streams
- Kinesis Firehose
- Dados analisados quando eles chegam, não há armazenamento
- Opcional ter lambda functions dentro do firehose
- Saída para o S3 ou Elasticsearch
- Kinesis Analytics
- Funciona com Streams e Firehose
- Analisar os dados em tempo real
- Armazenar no S3, Redshift ou Elasticsearch
- Kinesis Streams
- Acessar recursos da AWS depois que eles se autenticaram com um provedor de identidade baseado na web
- Amazon, Google, Facebook, etc
- Cognito = Serviço para Web Identity Federation
- Sign-up e sign-in para as apps
- Acesso para visitantes
- Identity broker entre a sua aplicação e os providers WebID
- Sincroniza dados para múltiplos devices
- Recomendado para todas as aplicações mobile da AWS
- Cria credenciais temporárias que mapeam para um IAM role
- Aplicação não precisa guardar credenciais AWS localmente
- User pools
- Diretórios de usuário
- Dá pra fazer login direto no user pool
- Cognito age como um Identity Broker
- Eles que fazem a comunicação com os web identity
- User based
- Identity Pools
- Fornecem acesso temporário a recursos da AWS como o S3 ou DynamoDB
- Ele que faz o trabalho de autenticação para obter as credenciais AWS
- Synchronization entre multiplos devices para alterações na conta
- Serviço de computação onde você sobe seu código, e só se preocupa com ele
- Código roda em resposta a eventos (triggers)
- Responder a requests HTTP usando api gateway ou chamadas API para SDKs
- Pricing:
- 1M requisições free, $.20 por 1M requisições depois disso
- Duração da função, depende da qtd. memória alocada, $.00001667 GB/s usado
- Scales out automaticamente
- Independentes, 1 evento = 1 fn
- Serverless, sem manutenção, downtime, etc
- Arquitetura fica complexa, AWS X-Ray ajuda a debugar lambdas
- Entender os triggers possíveis pra Lambda
- API Gateway
- AWS IoT
- Alexa Smart Home
- ALB
- CloudFront
- CloudWatch Logs
- CodeCommit
- DynamoDB
- CloudWatch Events
- Cognito Triggers (Auth)
- Kinesis
- Kit Alexa Skills
- S3
- SNS
- SQS
- Env variables, passar parametros estáticos
- Criptografia com KMS
- Possui suporte para hyperthreading
- Tipos de scaling
- Proactive Cyclic Scaling: Escala durante períodos de picos, ex. seg-sex 9am-5pm
- Event-based scaling/Predictive Scaling: Escala manual, anterior a algum evento ex. black friday
- Autoscaling (baseado na demanda): Usa métricas das instancias
- AWS reserva 5 hosts em cada subnet -> 2 são GW e Broadcast
- /24 -> número de 1s na máscara em binário
- Internet Gateway escala automaticamente, redundante e HA
- Instâncias devem ter IP público ou elastic IP pra acessar a internet usando o Internet Gateway
- IPv6 para tráfego de saída tem que usar Egress Only Internet Gateway. Pra tráfego IPV4, precisa do NAT Instance ou NAT Gateway
- Tolerância a falha = Um NAT gateweay por AZ
- VPC c/ Hardware VPN Access = a VPC usa a VPN on-premises do cliente
- VPG ou Virtual Private Gateway = "Âncora" do lado da AWS na conexão de VPN com on premises
- Customer Gateway = "Âncora" do lado do cliente (on premises)
- Toda conexão de VPN vai precisar de uma subnet privada
- VPC c/ tenância dedicada
- Compliance ou performance
- Pra desativar, basta usar CLI, SDK ou API
- Toda instância tem que ter um private IP, pro LB conseguir conversar com ela. Não há necessidade das instâncias terem public IP, mesmo se for um internet-facing LB
- Lambda pode ter um startup delay depois de ficar muito tempo sem usar
- NLB não suporta security groups, apenas ALB e CLB
- Estudar melhor
- File gateway funciona tipo um NFS para o S3
- Tamanho máximo de um arquivo é 5TB
- Tamanho máximo de um único PUT é 5GB
- Para arquivos maiores que 100MB, considerar o multipart upload
- Glacier
- Expedited e Bulk, estudar mais
- Multipart upload
- Não dá pra ir adicionando dados em um arquivo aberto
- Dá pra começar o upload antes de saber o tamanho final do objeto
- Pausar e continuar uploads
- Melhor vazão
- Recuperar de problemas de rede rapidamente
- Pre-signed URLs
- Servidor da aplicação gera a URL através de uma chamada de API para o S3
- URL pode expirar depois de um tempo
- ECS, Fargate e Elastic Beanstalk rodam containers nativamente
- EC2 não, precisa instalar o Docker
- Máximo IOPS/Instância é 75.000, mais que isso tem que ser Instance Store / Disco Efêmero
- Standby instances são para fault tolerance / disaster recovery, não devem ser usadas para reads
- Oracle RMAN e RAC não são suportados no RDS
- Aurora
- Dá pra criar endpoints personalizados para grupos de instâncias pré-definidos
- Automaticamente substitui as instâncias que estão unhealthy/stopped/terminated
- Armazenamento em colunas, redução de IO comparado a outras tecnologias
- Enhanced VPC Routing
- Requisições COPY e UNLOAD passam por dentro da VPC em vez de passar pela internet
- Permite usar os Flow Logs pra debugar essas requisições
- Alias records usa a configuração de TTL do serviço pra onde ele está apontando, não existe um default. Exemplo: ELB pode precisar de um TTL menor que um cloudfront
- AWS DNS não responde para requisições que saem de fora da VPC
- Tem que subir uma instância pra fazer zone transfers
- A ideia é um único consumer por mensagem. O que pode acontecer é acidentalmente (muitas mensagens na fila standard) ou visibility time out
- Permite personalização baseado no usuário logado
- Possível fazer failover de origins, especificando 2 origins e o CloudFront vai fazer o switch baseado no status code
- Host OS: hardware físico onde a AWS roda as virtualizações. AWS se responsabiliza por fazer o patching desses caras
- Segurança dos dados é responsabilidade do consumidor, a AWS fornece apenas os serviços para fazer isso
- Tamanho máximo de nome + valor deve ser 400KB
- É possível fazer reserva de capacidade
- NAT gateways para IPV6
- Avaliam todas as regras antes de liberar acesso
- Não existe "Firewall" da AWS, é implementado Stateful security groups e Stateless NACLs
- Injetar dados sensitivos nos containers através do AWS Secrets Manager ou AWS Systems Manager Parameter Store
- Criar um IAM Role pra permitir acesso ao KMS e Parameter Store
- Proteger de picos de tráfego: habilitar throttling e cache de resultados
- RDS
- Directory Service
- STS
- Redshift
- AWS Systems Manager
- CloudFront
- EBS
- First steps
- Find and define the applications
- Do a business impact analysis
- Set Recovery Point and Recovery Time Objectives
- RPO: Máximo perda de dados para uma aplicação
- RTO: Meta de tempo para reestabelecimento da aplicação (downtime)
- Spectrum of complexity (RPO/RTO mais lento para o mais rápido, do menos ao maixcomplexo)
- Backup & Restore
- RPO/RTO na casa das horas
- Menor prioridade
- Usa S3, Storage Gateway, etc
- Pilot light
- RPO/RTO na casa das dezenas de minutos
- Analogia dos aquecedores a gás, onde uma luz que fica sempre acesa pode acender o aquecimento de uma casa inteira
- Deixar alguns recursos críticos em outra região
- Replicar bancos cores
- Criar/escalar o resto que for necessrio
- Warm standby
- RPO/RTO na casa de minutos
- Recursos ficam sempre disponveis, mas eles podem ser menores
- Serviços críticos ao negcio
- Hot standby
- RPO/RTO em tempo real
- Auto-failover
- Multi-região
- Custo alto pra carai
- Backup & Restore