AWS Certified Solutions Developer Associate 2023

1. CICD

1.1. AWS CodeCommit

1.1.1. O controle de versão é a capacidade de entender as várias alterações que ocorreram no código ao longo do tempo (e possivelmente reverter)

1.1.2. Repositórios privados do Git, sem limite de tamanho nos repositórios (dimensionar perfeitamente)

1.1.3. Totalmente gerenciado, altamente disponível, Código apenas na conta da Nuvem AWS => maior segurança e conformidade

1.1.4. Integrado com Jenkins, AWS CodeBuild e outras ferramentas de CI

1.1.5. Segurança

1.1.5.1. Authentication

1.1.5.1.1. SSH Keys – os usuários da AWS podem configurar chaves SSH em seu console IAM

1.1.5.1.2. HTTPS – com assistente de credenciais AWS CLI ou credenciais Git para usuário IAM

1.1.5.2. Authorization

1.1.5.2.1. Políticas do IAM para gerenciar permissões de usuários/funções para repositórios

1.1.5.3. Encryption

1.1.5.3.1. Os repositórios são criptografados automaticamente em repouso usando o AWS KMS

1.1.5.3.2. Criptografado em trânsito (só pode usar HTTPS ou SSH – ambos seguros)

1.1.5.4. Cross-account Access

1.1.5.4.1. NÃO compartilhe suas chaves SSH ou suas credenciais da AWS

1.1.5.4.2. Use uma função IAM em sua conta da AWS e use AWS STS (API AssumeRole)

1.1.6. Aviso de analise de codigo

1.1.6.1. SNS + Lambda

1.2. AWS CodePipeline

1.2.1. Fluxo de trabalho visual para orquestrar seu CICD: source, build, test, deploy

1.2.2. Cada estágio do pipeline pode criar artefatos, armazenados em um bucket S3 e passados para o próximo estágio

1.2.3. Troubleshooting

1.2.3.1. CloudWatch Events (Amazon EventBridge)

1.2.3.2. Se o CodePipeline falhar em um estágio, seu pipeline será interrompido e você poderá obter informações no console

1.2.3.3. Se o pipeline não puder executar uma ação, certifique-se de que a "Função de serviço IAM" anexada tenha permissões IAM suficientes (Política IAM)

1.3. AWS CodeBuild

1.3.1. Um serviço de integração contínua (CI) totalmente gerenciado

1.3.2. Escalabilidade contínua (sem servidores para gerenciar ou provisionar – sem fila de construção)

1.3.3. Compilar código-fonte, executar testes, produzir pacotes de software

1.3.4. Cobrado por minuto para recursos de computação (tempo necessário para concluir as compilações)

1.3.5. Use imagens pré-empacotadas do Docker ou crie sua própria imagem personalizada do Docker

1.3.6. Segurança

1.3.6.1. Integração com KMS para criptografia de artefatos de compilação

1.3.6.2. IAM para permissões CodeBuild e VPC para segurança de rede

1.3.6.3. AWS CloudTrail para log de chamadas de API

1.3.7. Instruções de compilação: codifique o arquivo buildspec.yml ou insira manualmente no console

1.3.8. Os logs de saída podem ser armazenados no Amazon S3 e CloudWatch Logs

1.3.9. CloudWatch Metrics

1.3.9.1. monitorar estatísticas de compilação

1.3.10. CloudWatch Events

1.3.10.1. detectar compilações com falha e acionar notificações

1.3.11. CloudWatch Alarms

1.3.11.1. notificar se você precisa de “limites” para falhas

1.3.12. Projetos de construção podem ser definidos no CodePipeline ou CodeBuild

1.3.13. buildspec.yml

1.3.13.1. o arquivo deve estar na raiz do seu código

1.3.13.2. env

1.3.13.2.1. definição de variaveis de ambiente

1.3.13.2.2. variables

1.3.13.2.3. parameter-store

1.3.13.2.4. secrets-manager

1.3.13.3. phases

1.3.13.3.1. especificar comandos a serem executados

1.3.13.3.2. install

1.3.13.3.3. pre_build

1.3.13.3.4. build

1.3.13.3.5. post_build

1.3.13.4. artifacts

1.3.13.4.1. o que carregar no S3 (criptografado com KMS)

1.3.13.5. cache

1.3.13.5.1. arquivos para armazenar em cache (geralmente dependências) para S3 para aceleração de compilação futura

1.3.14. Local Build

1.3.14.1. Você pode executar o CodeBuild localmente em sua área de trabalho (depois de instalar o Docker)

1.3.14.2. Para isso, aproveite o CodeBuild Agent

1.4. AWS CodeDeploy

1.4.1. Cada instância EC2/servidor local deve estar executando o CodeDeploy Agent

1.4.2. O agente está pesquisando continuamente o AWS CodeDeploy para trabalho a fazer

1.4.3. Application + appspec.yml é extraído do GitHub ou S3

1.4.4. As instâncias do EC2 executarão as instruções de implantação em appspec.yml

1.4.5. O agente do CodeDeploy relatará o sucesso/falha da implantação

1.4.6. Deployment Configuration

1.4.6.1. Configurações

1.4.6.1.1. One At A Time

1.4.6.1.2. Half At A Time

1.4.6.1.3. All At Once

1.4.6.1.4. Custom

1.4.6.2. Falhas

1.4.6.2.1. As instâncias do EC2 permanecem no estado “Failed”

1.4.6.2.2. Novas implantações serão implantadas primeiro em instâncias com falha

1.4.6.2.3. Para reverter, reimplantar a implantação antiga ou habilitar a reversão automática para falhas

1.4.6.2.4. Se ocorrer uma reversão, o CodeDeploy reimplanta a última revisão válida conhecida como uma nova implantação (não uma versão restaurada)

1.4.6.3. Grupos de implantação

1.4.6.3.1. Um conjunto de instâncias marcadas do EC2

1.4.6.3.2. Diretamente para um ASG

1.4.6.3.3. Combinação de ASG / Tags para que você possa criar segmentos de implantação

1.4.6.3.4. Customização em scripts com ambiente DEPLOYMENT_GROUP_NAME var

1.4.7. Eventos

1.4.7.1. ValidateService

1.4.7.1.1. É o último evento do ciclo de vida da implantação. Ele é usado para verificar se a implantação foi concluída com êxito

1.4.7.2. AfterInstall

1.4.7.2.1. É um evento de ciclo de vida de implantação para tarefas como configurar seu aplicativo ou alterar permissões de arquivo

1.4.7.3. ApplicationStart

1.4.7.3.1. É um evento de ciclo de vida de implantação para reiniciar os serviços que foram interrompidos durante o ApplicationStop

1.4.7.4. AllowTraffic

1.4.7.4.1. Durante este evento de ciclo de vida de implantação, o tráfego da Internet tem permissão para acessar instâncias após uma implantação. Este evento é reservado para o agente do AWS CodeDeploy e não pode ser usado para executar scripts

1.5. AWS CodeStar

1.5.1. Uma solução integrada que agrupa: GitHub, CodeCommit, CodeBuild, CodeDeploy, CloudFormation, CodePipeline, CloudWatch

1.5.2. Crie rapidamente projetos “prontos para CICD” para EC2, Lambda, Elastic Beanstalk

1.6. AWS CodeArtifact

1.6.1. gerenciamento de artefato seguro, escalável e econômico para desenvolvimento de software

1.6.2. Os desenvolvedores e o CodeBuild podem recuperar as dependências diretamente do CodeArtifact

1.7. AWS CodeGuru

1.7.1. Um serviço baseado em ML para revisões de código automatizadas e recomendações de desempenho de aplicativos

1.7.2. CodeGuru Reviewer: revisões de código automatizadas para análise de código estático (desenvolvimento)

1.7.3. CodeGuru Profiler: visibilidade/recomendações sobre o desempenho do aplicativo durante o tempo de execução (produção)

1.8. AppSpec vs Buildspec

1.8.1. AppSpec

1.8.1.1. Mapeie os arquivos de origem na revisão do aplicativo para seus destinos na instância.

1.8.1.2. Especifique permissões personalizadas para arquivos implantados.

1.8.1.3. Especifique os scripts a serem executados em cada instância em vários estágios do processo de implantação.

1.8.2. Buildspec

1.8.2.1. É um arquivo usado pelo AWS CodeBuild para executar uma compilação

2. CloudFormation

2.1. Conceito

2.1.1. A exclusão de uma pilha exclui todos os artefatos criados por CloudFormation

2.1.2. As pilhas são identificadas por um nome

2.1.3. Para atualizar um modelo, não podemos editar os anteriores. Temos que reenviar uma nova versão do modelo para a AWS

2.1.4. Os modelos devem ser carregados no S3 e, em seguida, referenciados no CloudFormation

2.1.5. É uma forma declarativa de descrever sua infraestrutura AWS, para quaisquer recursos (a maioria deles é suportada)

2.2. Deploy Templates

2.2.1. Manual

2.2.1.1. Editando modelos no CloudFormation Designer

2.2.1.2. Usando o console para inserir parâmetros, etc.

2.2.2. Automatico

2.2.2.1. Editando modelos em um arquivo YAML

2.2.2.2. Usando a AWS CLI para implantar os modelos

2.2.2.3. Maneira recomendada quando você deseja automatizar totalmente seu fluxo

2.3. Componentes

2.3.1. Resources

2.3.1.1. Seus recursos da AWS declarados no modelo (OBRIGATÓRIO)

2.3.2. Parameters

2.3.2.1. As entradas dinâmicas para o seu modelo

2.3.3. Mappings

2.3.3.1. As variáveis estáticas para seu modelo

2.3.4. Outputs

2.3.4.1. Referências ao que foi criado

2.3.5. Conditionals

2.3.5.1. Lista de condições para realizar a criação de recursos

2.3.5.2. Não podem ser usadas na seção Parâmetros

2.3.6. Metadata

2.3.7. Mappings vs Parameters

2.3.7.1. Mappings

2.3.7.1.1. Quando sabe com antecedência todos os valores que podem ser obtidos e que podem ser deduzidos de variáveis como Região, az, etc.

2.3.7.2. Parameters

2.3.7.2.1. Use parâmetros quando os valores forem realmente específicos do usuário

2.4. Pseudo Parameters

2.4.1. A AWS nos oferece pseudoparâmetros em qualquer modelo CloudFormation.

2.4.2. Estes podem ser usados a qualquer momento e são ativados por padrão

2.5. Outputs

2.5.1. A seção Outputs declara valores de outputs opcionais que podemos importar para outras pilhas (se você exportá-los primeiro)!

2.5.2. Útil, por exemplo, se você definir um CloudFormation de rede e gerar as variáveis, como VPC ID e seus IDs de sub-rede

2.5.3. É a melhor maneira de executar uma cross stack de colaboração, pois permite que o especialista cuide de sua própria parte da pilha

2.5.4. Não pode excluir uma pilha do CloudFormation se suas saídas estiverem sendo referenciadas por outra pilha do CloudFormation

2.5.5. Os valores de saída exportados no CloudFormation devem ter nomes exclusivos em uma única região

2.6. Funções intrisecas

2.6.1. Ref.

2.6.1.1. Função pode ser aproveitada para referenciar

2.6.1.1.1. Parâmetros => retorna o valor do parâmetro

2.6.1.1.2. Resources => retorna o ID físico do recurso subjacente (ex: EC2 ID)

2.6.1.1.3. Atalho !Ref

2.6.2. Fn::GetAtt

2.6.2.1. Os atributos são anexados a todos os recursos que você cria

2.6.3. Fn::FindInMap

2.6.3.1. Retorna um valor nomeado de uma chave específica

2.6.3.2. !FindInMap [ MapName, TopLevelKey, SecondLevelKey ]

2.6.4. Fn::Join

2.6.4.1. Junte valores com um delimitador

2.6.4.2. { "Fn::Join" : [ "delimiter", [ comma-delimited list of values ] ] }

2.6.4.3. "Fn::Join" : [ ":", [ "a", "b", "c" ] ] = a : b : c

2.6.5. Fn::Sub

2.6.5.1. é usado para substituir variáveis de um texto

2.6.6. Condition Functions (Fn::If, Fn::Not, Fn::Equals, etc…)

2.6.7. Fn::ImportValue

2.6.7.1. Em seguida, criamos um segundo modelo que aproveita esse grupo de segurança

2.6.7.2. Você não pode excluir a pilha subjacente até que todas as referências sejam excluídas também

2.7. Rollbacks

2.7.1. Falha na criação

2.7.1.1. Padrão: tudo reverte (é excluído). Podemos olhar para o log

2.7.1.2. Opção para desativar a reversão e solucionar o que aconteceu

2.8. ChangeSet

2.8.1. Analisa as próximas alterações em uma atualização de pilha do CloudFormation sem realmente executá-las

2.9. Cross vs Nested Stacks

2.9.1. Cross

2.9.1.1. Útil quando as pilhas têm ciclos de vida diferentes

2.9.1.2. Use Outputs Export and Fn::ImportValue

2.9.1.3. Quando você precisa passar valores de exportação para muitas pilhas (VPC Id, etc…)

2.9.2. Nested

2.9.2.1. Útil quando os componentes devem ser reutilizados

2.9.2.2. Ex: reutilizar como configurar corretamente um Application Load Balancer

2.9.2.3. A pilha aninhada é importante apenas para a pilha de nível superior (não é compartilhada)

2.10. StackSets

2.10.1. Crie, atualize ou exclua pilhas em várias contas e regiões com uma única operação

2.10.2. Quando você atualiza um conjunto de pilha, todas as instâncias de pilha associadas são atualizadas em todas as contas e regiões

2.11. Drift

2.11.1. Visualiza mudanças realizadas manualmente

3. Monitoring

3.1. CloudWatch

3.1.1. Metrics

3.1.1.1. Métrica é uma variável a monitorar (CPUUtilization, NetworkIn…) e pertence a namespaces

3.1.1.2. Até 30 dimensões por métrica

3.1.1.3. As métricas têm carimbos de data/hora

3.1.2. Custom

3.1.2.1. Possibilidade de definir e enviar suas próprias métricas personalizadas para o CloudWatch

3.1.2.2. Usar chamada de API PutMetricData

3.1.2.3. Importante: aceita pontos de dados métricos duas semanas atrás e duas horas no futuro

3.1.3. Log

3.1.3.1. Grupos de log: nome arbitrário, geralmente representando um aplicativo

3.1.3.2. Fluxo de log: instâncias dentro do aplicativo/arquivos de log/contêineres

3.1.3.3. Pode definir políticas de expiração de log (nunca expirar, 30 dias, etc.)

3.1.3.4. O CloudWatch Logs pode enviar logs para: S3, Kinesis, OpenSearch, Lambda

3.1.4. Agent

3.1.4.1. Por padrão, nenhum log da sua máquina EC2 irá para o CloudWatch

3.1.4.2. Você precisa executar um agente do CloudWatch no EC2 para enviar os arquivos de log que deseja

3.1.4.3. Verifique se as permissões do IAM estão corretas

3.1.4.4. O agente de log do CloudWatch também pode ser configurado no local

3.1.5. Alarms

3.1.5.1. Os alarmes são usados para acionar notificações para qualquer métrica

3.1.5.2. Alvos principais: ECS, ASG e SNS

3.1.5.3. Single metric CloudWatch Alarms

3.1.5.4. Composite Alarms monitoram multiplos estados de alarmes

3.1.5.5. Os alarmes podem ser criados com base nos filtros de métricas do CloudWatch Logs

3.1.6. Events

3.1.6.1. Interceptar eventos de serviços da AWS (Fontes)

3.1.6.2. Fontes de exemplo: EC2 Instance Start, CodeBuild Failure, S3, Trusted Advisor

3.1.6.3. Pode interceptar qualquer chamada de API com integração CloudTrail

3.1.6.4. Uma carga útil JSON é criada a partir do evento e passada para um destino

3.1.7. EventBridge

3.1.7.1. Conceitos

3.1.7.1.1. É a próxima evolução do CloudWatch Events

3.1.7.1.2. Default Event Bus

3.1.7.1.3. Partner Event Bus

3.1.7.1.4. Custom Event Buses

3.1.7.1.5. Você pode arquivar eventos (todos/filtro) enviados para um barramento de eventos (indefinidamente ou período definido)

3.1.7.1.6. Capacidade de reproduzir eventos arquivados

3.1.7.1.7. Regras: como processar os eventos (como CloudWatch Events)

3.1.7.2. Schema Registry

3.1.7.2.1. O EventBridge pode analisar os eventos em seu barramento e inferir o esquema

3.1.7.2.2. Schema Registry permite gerar código para sua aplicação, que saberá antecipadamente como os dados estão estruturados no barramento de eventos

3.1.7.2.3. O esquema pode ser versionado

3.1.7.3. Resource-based Policy

3.1.7.3.1. Gerenciar permissões para um barramento de eventos específico

3.1.7.3.2. Exemplo: permitir/negar eventos de outra conta da AWS ou região da AWS

3.1.7.3.3. Caso de uso: agregue todos os eventos de sua organização da AWS em uma única conta ou região da AWS da AWS

3.2. X-Ray

3.2.1. Conceitos

3.2.1.1. Encontrar erros e exceções

3.2.1.2. Compreender as dependências em uma arquitetura de microsserviços

3.2.1.3. Identificar problemas de serviço, Revise o comportamento da solicitação

3.2.1.4. Resolução de problemas de desempenho (gargalos)

3.2.2. Compatibilidade

3.2.2.1. AWS Lambda, Elastic Beanstalk, ECS, ELB, API Gateway, EC2 Instances ou qualquer servidor de aplicativos (mesmo no local)

3.2.2.2. O rastreamento é uma maneira completa de seguir um “pedido”

3.2.2.3. Cada componente que lida com a solicitação adiciona seu próprio “traço”

3.2.2.4. O rastreamento é feito de segmentos (+ sub segmentos)

3.2.3. Habilitar

3.2.3.1. I) Seu código (Java, Python, Go, Node.js, .NET) deve importar o AWS SDK do Raio-X

3.2.3.2. 2) Instale o daemon do X-Ray ou ative o X-Ray AWS Integration

3.2.4. Troubleshooting

3.2.4.1. Se o X-Ray não estiver funcionando no EC2

3.2.4.1.1. Certifique-se de que a função EC2 IAM tenha as permissões adequadas

3.2.4.1.2. Verifique se a instância do EC2 está executando o X-Ray Daemon

3.2.4.2. Para habilitar no AWS Lambda

3.2.4.2.1. Certifique-se de que ele tenha uma função de execução do IAM com a política adequada (AWSX-RayWriteOnlyAccess)

3.2.4.2.2. Certifique-se de que o X-Ray seja importado no código

3.2.5. Concepts

3.2.5.1. Segmentos: cada aplicativo/serviço os enviará

3.2.5.2. Subsegmentos: se você precisar de mais detalhes em seu segmento

3.2.5.3. Rastreamento: segmentos coletados juntos para formar um rastreamento de ponta a ponta

3.2.5.4. Amostragem: diminuir a quantidade de requisições enviadas ao Raio-X, reduzir custo

3.2.5.5. Anotações: pares de chave-valor usados para indexar rastreamentos e usar com filtros

3.2.5.6. Metadados: pares de chave-valor, não indexados, não usados para pesquisa

3.2.6. Opções de integração ECS + X-Ray

3.2.6.1. ECS Cluster

3.2.6.1.1. X-Ray Container as a Daemon

3.2.6.1.2. X-Ray Container as a “Side Car”

3.2.6.2. Fargate Cluster

3.2.6.2.1. Um fargate por container

3.2.7. X-Ray sampling

3.2.7.1. Quando funciona o rastreamento local e nao funciona no EC2, isso não ajuda a determinar a causa da falha

3.3. CloudTrail

3.3.1. Conceitos

3.3.1.1. Se um recurso for excluído da AWS, investigue o CloudTrail primeiro!

3.3.1.2. CloudTrail é ativado por padrão!

3.3.1.3. Obtenha um histórico de eventos/chamadas de API feitas em sua conta da AWS

3.3.1.4. Pode colocar logs do CloudTrail no CloudWatch Logs ou S3

3.3.1.5. Uma trilha pode ser aplicada a todas as regiões (padrão) ou a uma única região.

3.3.1.6. Fornece governança, conformidade e auditoria para sua conta da AWS

3.3.2. Events

3.3.2.1. Management Events

3.3.2.1.1. Operações executadas em recursos na conta AWS

3.3.2.1.2. Por padrão, as trilhas são configuradas para registrar eventos de gerenciamento.

3.3.2.1.3. Pode separar eventos de leitura dos de gravação

3.3.2.2. Data Events

3.3.2.2.1. Por padrão, os eventos de dados não são registrados (por causa das operações de alto volume)

3.3.2.2.2. Exemplo: Atividade em nível de objeto do Amazon S3

3.3.2.3. CloudTrail Insights Events

3.3.2.3.1. Habilite o CloudTrail Insights para detectar atividades incomuns em sua conta

3.3.2.3.2. Analisa eventos normais de gerenciamento para criar uma linha de base

3.3.2.3.3. Analisa eventos de gravação para detectar padrões incomuns

3.3.3. Retention

3.3.3.1. Os eventos são armazenados por 90 dias no CloudTrail

3.3.3.2. Para manter os eventos além desse período, registre-os no S3 e use o Athena

4. Mensageria

4.1. SQS

4.1.1. Taxa de transferência ilimitada, número ilimitado de mensagens na fila

4.1.2. Retenção padrão de mensagens: 4 dias, máximo de 14 dias

4.1.3. Baixa latência, Limitação de 256 KB por mensagem

4.1.4. Pode ter mensagens duplicadas, pode ter mensagens fora de ordem

4.1.5. Long Polling

4.1.5.1. Quando um consumidor solicita mensagens da fila, ele pode opcionalmente “aguardar” a chegada das mensagens se não houver nenhuma na fila

4.1.5.2. LongPolling diminui o número de chamadas de API feitas ao SQS enquanto aumenta a eficiência e reduz a latência do seu aplicativo

4.1.5.3. O tempo de espera pode ser entre 1 segundo a 20 segundos (20 segundos preferível)

4.1.6. Delay queue

4.1.6.1. Permitem que adie a entrega de novas mensagens para uma fila por vários segundos, por exemplo, quando seu aplicativo consumidor precisar de mais tempo para processar mensagens

4.1.6.2. Todas mensagens enviadas para a fila permanecerão invisíveis para os consumidores durante o período de atraso

4.1.6.3. O atraso padrão (mínimo) para uma fila é 0 segundos. O máximo é 15 minutos.

4.1.6.4. DLQ de uma fila FIFO também deve ser uma fila FIFO e a fila Padrão também deve ser uma fila Padrão

4.1.7. Dead-letter queues

4.1.7.1. São usadas por outras filas (filas de origem) como destino para mensagens que não podem ser processadas (consumidas) com êxito

4.1.8. Visibility timeout

4.1.8.1. É um período durante o SQS impede que outros consumidores recebam e processem uma determinada mensagem

4.1.8.2. O tempo limite de visibilidade padrão para uma mensagem é de 30 segundos. O mínimo é 0 segundos. O máximo é de 12 horas

4.1.8.3. Não pode usar o tempo limite de visibilidade para adiar a entrega de novas mensagens na fila por alguns segundo

4.1.9. SQS Temporary Queue Client

4.1.9.1. Request-Response Systems

4.1.10. Operações

4.1.10.1. CreateQueue (MessageRetentionPeriod), DeleteQueue

4.1.10.2. PurgeQueue: remove todas mensagens da fila

4.1.10.3. SendMessage (DelaySeconds), ReceiveMessage, DeleteMessage

4.1.10.4. MaxNumberOfMessages: default 1, max 10 (for ReceiveMessage API)

4.1.10.5. ReceiveMessageWaitTimeSeconds: Long Polling

4.1.10.6. ChangeMessageVisibility: change the message timeout

4.1.11. Deduplicação

4.1.11.1. Intervalo de 5min

4.1.11.2. Desduplicação baseada em conteúdo: fará um hash SHA-256 do corpo da mensagem

4.1.11.3. Forneça explicitamente um ID de eliminação de duplicação de mensagens

4.1.12. Message Grouping

4.1.12.1. Se especificar o mesmo valor de MessageGroupID em uma fila FIFO, poderá ter apenas um consumidor e todas as mensagens estarão em ordem

4.1.12.2. Para ordenação no nível de um subconjunto de mensagens, especifique valores diferentes para MessageGroupID

4.1.12.2.1. As mensagens que compartilham um ID de grupo de mensagens comum estarão em ordem dentro do grupo

4.1.12.2.2. Cada ID de grupo pode ter um consumidor diferente (processamento paralelo!)

4.1.12.2.3. A ordem entre os grupos não é garantida

4.2. SNS

4.2.1. Cada assinante do tópico receberá todas as mensagens (nota: novo recurso para filtrar mensagens)

4.2.2. Criptografia

4.2.2.1. Criptografia em trânsito usando API HTTPS

4.2.2.2. Criptografia em repouso usando chaves KMS

4.2.2.3. Criptografia do lado do cliente - Gerencia por conta própria

4.2.3. SNS + SQS: Fan Out

4.2.3.1. Uma vez no SNS, receba em todas as filas do SQS que são assinantes

4.2.3.2. Totalmente desacoplado, sem perda de dados

4.2.3.3. O SQS permite: persistência de dados, processamento atrasado e novas tentativas de trabalho

4.2.3.4. Capacidade de adicionar mais assinantes SQS ao longo do tempo

4.2.3.5. Certifique-se de que sua política de acesso à fila SQS permita que o SNS grave

4.2.4. Conceitos

4.2.4.1. Funout é um cenário onde uma única mensagem é entregue para mais de um serviço

4.3. Kinesis

4.3.1. Facilita a coleta, o processamento e a análise de dados de streaming em tempo real

4.3.2. Faça a ingestão de dados em tempo real, como: logs de aplicativos, métricas, fluxos de cliques do site, telemetria IoT

4.3.3. Tipos

4.3.3.1. Data Streams

4.3.3.1.1. Retenção entre 1 dia a 365 dias, Capacidade de reprocessar (reproduzir) dados

4.3.3.1.2. Depois que os dados são inseridos não podem ser excluídos (imutabilidade)

4.3.3.1.3. Dados que compartilham a mesma partição vão para o mesmo shard (ordenação)

4.3.3.1.4. Produtores: AWS SDK, Kinesis Producer Library (KPL), Kinesis Agent

4.3.3.1.5. Consumidores

4.3.3.1.6. Capacidade

4.3.3.1.7. Operações

4.3.3.2. Data Firehose

4.3.3.2.1. Pague pelos dados que passam pelo Firehose

4.3.3.2.2. Suporta muitos formatos de dados, conversões, transformações, compressão

4.3.3.2.3. Oferece suporte a transformações de dados personalizadas usando o AWS Lambda

4.3.3.2.4. Pode enviar com falha ou todos os dados para um bucket do S3 de backup

4.3.3.2.5. Quase em tempo real

4.3.3.3. Data Streams vs Firehose

4.3.3.3.1. Streams

4.3.3.3.2. Firehose

4.3.3.4. SQS vs SNS vs Kinesis

4.3.3.4.1. SQS

4.3.3.4.2. SNS

4.3.3.4.3. Kinesis

4.3.3.5. Data Analytics

4.3.3.5.1. Realize análises em tempo real no Kinesis Streams usando SQL

4.3.3.5.2. Totalmente gerenciado, sem servidores para provisionar, Escalonamento automático, Análise em tempo real

4.3.3.5.3. Pague pela taxa de consumo real

4.3.3.5.4. Pode criar fluxos a partir de consultas em tempo real

4.3.3.6. Ordenação

4.3.3.6.1. Kinesis

4.3.3.6.2. SQS

4.4. EventBridge

4.4.1. Recomendado quando você deseja criar um aplicativo que reaja a eventos de aplicativos SaaS e/ou serviços da AWS

4.4.2. Único serviço baseado em eventos que se integra diretamente com parceiros SaaS de terceiros

4.4.3. Ingere automaticamente eventos de mais de 90 serviços da AWS sem exigir que os desenvolvedores criem recursos em suas contas

4.5. Active MQ

4.5.1. Os aplicativos tradicionais executados no local podem usar protocolos abertos, como: MQTT, AMQP, STOMP, Openwire, WSS

4.5.2. Ao migrar para a nuvem, em vez de reprojetar o aplicativo para usar SQS e SNS, podemos usar o Amazon MQ

4.5.3. Amazon MQ = Apache ActiveMQ gerenciado

4.5.4. Não “escalonam” tanto quanto SQS / SNS

4.5.5. É executado em uma máquina dedicada, pode ser executado em HA com failover

4.5.6. Possui recurso de fila (~SQS) e recursos de tópico (~SNS)

5. Serverless

5.1. Synchronous Invocations

5.1.1. User Invoked

5.1.1.1. Elastic Load Balancing (Application Load Balancer)

5.1.1.1.1. a função deve ser registrada em um grupo de destino

5.1.1.2. Amazon API Gateway

5.1.1.3. Amazon CloudFront (Lambda@Edge)

5.1.1.4. Amazon S3 Batch

5.1.2. Service Invoked

5.1.2.1. Amazon Cognito

5.1.2.2. AWS Step Functions

5.1.3. Other Services

5.1.3.1. Amazon Lex

5.1.3.2. Amazon Alexa

5.1.3.3. Amazon Kinesis Data Firehose

5.2. Asynchronous Invocations

5.2.1. S3, SNS, CloudWatch Events, os eventos são colocados em uma fila de eventos

5.2.2. Verifique se o processamento é idempotente (no caso de novas tentativas)

5.2.3. Se a função for repetida, você verá entradas de logs duplicadas no CloudWatch Logs

5.3. Event Source Mapping

5.3.1. Denominador comum: os registros precisam ser pesquisados na origem

5.3.2. Sua função do Lambda é invocada de forma síncrona

5.3.3. SQS & SQS FIFO

5.3.3.1. Event Source Mapping pesquisará o SQS (Long Polling)

5.3.3.2. Especifique o tamanho do lote (1-10 mensagens)

5.3.3.3. Recomendado: defina o tempo limite de visibilidade da fila para 6x o tempo limite de sua função Lambda

5.3.3.4. Para usar DLQ

5.3.3.4.1. Configure na fila SQS, não Lambda (DLQ para Lambda é apenas para invocações assíncronas) ou use um destino Lambda para falhas

5.3.4. Queues & Lambda

5.3.4.1. O Lambda oferece suporte ao processamento em ordem para filas FIFO, expandindo para o número de grupos de mensagens ativos

5.3.4.2. Para filas padrão, os itens não são necessariamente processados em ordem

5.3.4.3. O Lambda escala para processar uma fila padrão o mais rápido possível

5.3.4.4. Quando ocorre um erro, os lotes são devolvidos à fila como itens individuais e podem ser processados em um agrupamento diferente do lote original

5.3.4.5. Ocasionalmente, o mapeamento da origem do evento pode receber o mesmo item da fila duas vezes, mesmo que nenhum erro de função tenha ocorrido

5.3.4.6. O Lambda exclui itens da fila depois que eles são processados com sucesso

5.3.4.7. Você pode configurar a fila de origem para enviar itens para uma fila de devoluções se eles não puderem ser processados

5.3.5. Streams & Lambda (Kinesis & DynamoDB)

5.3.5.1. Um mapeamento de fonte de evento cria um iterador para cada estilhaço, processa itens em ordem

5.3.5.2. Comece com novos itens, desde o início ou a partir do carimbo de data/hora

5.3.5.3. Os itens processados não são removidos do fluxo (outros consumidores podem lê-los)

5.3.5.4. Baixo tráfego: use janela de lote para acumular registros antes do processamento

5.3.5.5. Error Handling

5.3.5.5.1. Por padrão, se sua função retornar um erro, todo o lote será reprocessado até que a função seja bem-sucedida ou os itens do lote expirem.

5.3.5.5.2. Para garantir o processamento em ordem, o processamento do estilhaço afetado é pausado até que o erro seja resolvido

5.3.5.5.3. Eventos descartados podem ir para um Destino

5.3.6. Lambda Event Mapper Scaling

5.3.6.1. Kinesis Data Streams & DynamoDB Streams

5.3.6.1.1. Uma invocação do Lambda por estilhaço de stream

5.3.6.1.2. Se você usar paralelização, até 10 lotes processados por estilhaço simultaneamente

5.3.6.2. SQS Standard

5.3.6.2.1. Lambda adiciona mais 60 instâncias por minuto para escalar

5.3.6.2.2. Até 1000 lotes de mensagens processadas simultaneamente

5.3.6.3. SQS FIFO

5.3.6.3.1. Mensagens com o mesmo GroupID serão processadas na ordem

5.3.6.3.2. A função do Lambda é dimensionada para o número de grupos de mensagens ativos

5.4. Lambda Execution Role

5.4.1. Concede as permissões da função Lambda aos serviços/recursos da AWS

5.4.2. Quando você usa um event source mapping para invocar sua função, o Lambda usa a função de execução para ler os dados do evento.

5.4.3. Prática recomendada: crie uma função de execução do Lambda por função

5.5. Lambda Resource Based Policies

5.5.1. Use políticas baseadas em recursos para conceder permissão a outras contas e serviços da AWS para usar seus recursos do Lambda

5.5.2. Semelhante às políticas de bucket S3 para bucket S3

5.5.3. Quando um serviço da AWS como o Amazon S3 chama sua função Lambda, a política baseada em recursos fornece acesso

5.6. Lambda Environment Variables

5.6.1. As variáveis de ambiente estão disponíveis para o seu código

5.6.2. O Lambda Service também adiciona suas próprias variáveis de ambiente do sistema

5.6.3. Útil para armazenar segredos (criptografados por KMS)

5.6.4. Os segredos podem ser criptografados pela chave de serviço do Lambda ou por sua própria CMK

5.7. Lambda Tracing with X-Ray

5.7.1. Ativar na configuração do Lambda (Active Tracing)

5.7.2. Executa o daemon X-Ray para você

5.7.3. Use o AWS X-Ray SDK no código

5.7.4. Variáveis de ambiente para se comunicar com o X-Ray

5.7.4.1. _X_AMZN_TRACE_ID: contém o cabeçalho de rastreamento

5.7.4.2. AWS_XRAY_CONTEXT_MISSING: por padrão, LOG_ERROR

5.7.4.3. AWS_XRAY_DAEMON_ADDRESS: o Daemon do X-Ray IP_ADDRESS:PORT

5.8. Lambda in VPC

5.8.1. Por padrão, sua função Lambda é iniciada fora de sua própria VPC (em uma VPC de propriedade da AWS)

5.8.2. Não tem acesso a internet, Portanto, ele não pode acessar recursos em sua VPC

5.8.3. Você deve definir o VPC ID, as sub-redes e os grupos de segurança

5.8.4. O Lambda criará uma ENI em suas sub-redes

5.8.5. A implantação de uma função do Lambda em uma sub-rede pública não fornece acesso à Internet ou um IP público

5.8.6. A implantação de uma função Lambda em uma sub-rede privada fornece acesso à Internet se você tiver um gateway/instância NAT

5.8.7. Você pode usar VPC endpoints para acessar de forma privada os serviços da AWS sem um NAT

5.9. Lambda Function Configuration

5.9.1. De 128 MB a 10 GB em incrementos de 1 MB

5.9.2. Quanto mais RAM você adicionar, mais créditos vCPU você obterá

5.9.3. Com 1.792 MB, uma função tem o equivalente a uma vCPU completa

5.9.4. Após 1.792 MB, você obtém mais de uma CPU e precisa usar multi-threading em seu código para se beneficiar dela (até 6 vCPU)

5.9.5. Se seu aplicativo for vinculado à CPU (computação pesada), aumente a RAM

5.9.6. Tempo limite: padrão 3 segundos, o máximo é 900 segundos (15 minutos)

5.10. Lambda Execution Context

5.10.1. O contexto de execução é um ambiente de tempo de execução temporário que inicializa quaisquer dependências externas do seu código lambda

5.10.2. É mantido por algum tempo em antecipação a outra chamada de função do Lambda

5.10.3. A próxima chamada de função pode “reutilizar” o contexto para tempo de execução e economizar tempo na inicialização de objetos de conexão

5.11. Lambda Concurrency and Throttling

5.11.1. Limite de simultaneidade: até 1.000 execuções simultâneas

5.11.2. Pode definir uma “simultaneidade reservada” no nível da função (=limite)

5.11.3. Cada invocação acima do limite de simultaneidade acionará um “Throttle”

5.11.4. Throttle behavior

5.11.4.1. Se a chamada síncrona => return ThrottleError - 429

5.11.4.2. Se a chamada assíncrona => tente novamente automaticamente e, em seguida, vá para DLQ

5.11.5. Se você precisar de um limite maior, abra um ticket de suporte

5.12. Concurrency and Asynchronous Invocations

5.12.1. Se a função não tiver simultaneidade suficiente disponível para processar todos os eventos, as solicitações adicionais serão limitadas.

5.12.2. Para erros de limitação (429) e erros do sistema (série 500), o Lambda retorna o evento para a fila e tenta executar a função novamente por até 6 horas.

5.12.3. O intervalo de repetição aumenta exponencialmente de 1 segundo após a primeira tentativa até um máximo de 5 minutos.

5.12.4. Cold Starts & Provisioned Concurrency

5.12.4.1. Cold Starts

5.12.4.1.1. Nova instância => o código é carregado e o código fora do manipulador é executado (init)

5.12.4.1.2. Se o init for grande (código, dependências, SDK…) este processo pode demorar algum tempo.

5.12.4.1.3. A primeira solicitação atendida por novas instâncias tem latência maior que as demais

5.12.4.2. Provisioned Concurrency

5.12.4.2.1. A simultaneidade é alocada antes que a função seja invocada (com antecedência)

5.12.4.2.2. Portanto, o cold start nunca acontece e todas as invocações têm baixa latência

5.12.4.2.3. O Application Auto Scaling pode gerenciar a simultaneidade (programação ou utilização de destino)

5.13. Lambda and CloudFormation

5.13.1. Inline

5.13.1.1. Você não pode incluir dependências de função com funções embutidas

5.13.1.2. Use a propriedade Code.ZipFile

5.13.1.3. As funções inline são muito simples

5.13.2. S3

5.13.2.1. Você deve armazenar o zip do Lambda no S3 e deve consultar o local do zip do S3 no código do CloudFormation

5.13.2.2. Se você atualizar o código no S3, mas não atualizar S3Bucket, S3Key ou S3ObjectVersion, o CloudFormation não atualizará sua função

5.14. Versions

5.14.1. Quando você trabalha em uma função do Lambda, nós trabalhamos em $LATEST

5.14.2. Quando estivermos prontos para publicar uma função do Lambda, criamos uma versão

5.14.3. As versões são imutáveis e têm números de versão crescentes As versões obtêm seu próprio ARN (Amazon Resource Name)

5.14.4. Versão = código + configuração (nada pode ser alterado - imutável)

5.14.5. Cada versão da função lambda pode ser acessada

5.15. Aliases

5.15.1. Aliases são "ponteiros" para versões de funções do Lambda

5.15.2. Podemos definir aliases “dev”, “test”, “prod” e fazer com que apontem para diferentes versões de lambda

5.15.3. Os aliases são mutáveis e permitem a implantação do Canary atribuindo pesos às funções lambda

5.15.4. Aliases permitem uma configuração estável de nossos gatilhos/destinos de eventos

5.15.5. Aliases têm seus próprios ARNs

5.15.6. Aliases não podem fazer referência a aliases

5.16. Lambda & CodeDeploy

5.16.1. O CodeDeploy pode ajudá-lo a automatizar a mudança de tráfego para aliases do Lambda

5.16.2. O recurso é integrado à estrutura do SAM

5.16.3. Linear

5.16.3.1. Aumente o tráfego a cada N minutos até 100%

5.16.3.1.1. Linear10PercentEvery3Minutes

5.16.3.1.2. Linear10PercentEvery10Minutes

5.16.4. Canary

5.16.4.1. tente X por cento e depois 100%

5.16.4.1.1. Canary10Percent5Minutes

5.16.4.1.2. Canary10Percent30Minutes

5.16.5. AllAtOnce

5.16.5.1. Imediamente

5.17. Lambda Limits

5.17.1. Execution

5.17.1.1. Alocação de memória: 128 MB – 10 GB (incrementos de 1 MB)

5.17.1.2. Tempo máximo de execução: 900 segundos (15 minutos)

5.17.1.3. Variáveis de ambiente (4 KB)

5.17.1.4. Capacidade do disco no “contêiner de função” (em /tmp): 512 MB a 10 GB

5.17.1.5. Execuções de simultaneidade: 1000 (pode ser aumentada)

5.17.2. Deployments

5.17.2.1. Tamanho da implantação da função Lambda (.zip compactado): 50 MB

5.17.2.2. Tamanho da implantação descompactada (código + dependências): 250 MB

5.17.2.3. Pode usar o diretório /tmp para carregar outros arquivos na inicialização

5.17.2.4. Tamanho das variáveis de ambiente: 4 KB

5.18. Lambda Best Practices

5.18.1. Realize trabalhos pesados fora do seu manipulador de funções

5.18.2. Minimize o tamanho do pacote de implantação para suas necessidades de tempo de execução

5.18.3. Evite usar código recursivo, nunca faça com que uma função Lambda chame a si mesma

6. AWS API Gateway

6.1. Não é compativel com STS

6.2. Integrations High Level

6.2.1. Lambda Function

6.2.1.1. Chamar a função Lambda

6.2.1.2. Maneira fácil de expor a API REST suportada pelo AWS Lam

6.2.2. HTTP

6.2.2.1. Expor endpoints HTTP no back-end

6.2.2.2. Exemplo: API HTTP interna no local, Application Load Balancer

6.2.2.3. Por que? Adicione limitação de taxa, cache, autenticações de usuário, chaves de API, etc…

6.2.3. AWS Service

6.2.3.1. Exponha qualquer API da AWS por meio do API Gateway

6.2.3.2. Exemplo: iniciar um fluxo de trabalho do AWS Step Function, postar uma mensagem no SQS

6.2.3.3. Por que? Adicionar autenticação, implantar publicamente, controle de taxa

6.3. Endpoint Types

6.3.1. Edge-Optimized (default)

6.3.1.1. Para clientes globais

6.3.1.2. As solicitações são roteadas pelos pontos de presença do CloudFront (melhora a latência)

6.3.1.3. O API Gateway ainda vive em apenas uma região

6.3.2. Regional

6.3.2.1. Para clientes dentro da mesma região

6.3.2.2. Poderia combinar manualmente com o CloudFront (mais controle sobre as estratégias de cache e distribuição)

6.3.3. Private

6.3.3.1. Só pode ser acessado de seu VPC usando um VPC endpoint de interface (ENI)

6.3.3.2. Use uma política de recursos para definir o acesso

6.4. Security

6.4.1. User Authentication through

6.4.1.1. IAM Roles (útil para aplicativos internos)

6.4.1.2. Cognito (identidade para usuários externos – exemplo de usuários móveis)

6.4.1.3. Autorizador personalizado (sua própria lógica)

6.4.2. Custom Domain Name HTTPS security through integration with AWS Certificate Manager (ACM)

6.4.2.1. Se estiver usando o endpoint otimizado para borda, o certificado deve estar em us-east-1

6.4.2.2. Se estiver usando endpoint regional, o certificado deve estar na região do API Gateway

6.4.2.3. Deve configurar o registro CNAME ou A-alias no Route 53

6.5. Deployment Stages

6.5.1. As alterações são implantadas em “Estágios” (quantos você quiser)

6.5.2. Use a nomenclatura que desejar para os estágios (dev, test, prod)

6.5.3. Cada estágio tem seus próprios parâmetros de configuração

6.5.4. Os estágios podem ser revertidos à medida que um histórico de implantações é mantido

6.6. Variaveis de estágio

6.6.1. Variáveis de estágio são como variáveis de ambiente para API Gateway

6.6.2. Use-os para alterar os valores de configuração que mudam frequentemente

6.6.3. As variáveis de estágio são passadas para o objeto "contexto" no AWS Lambda

6.7. Gateway Stage Variables & Lambda Aliases

6.7.1. Criamos uma variável de estágio para indicar o alias Lambda correspondente

6.7.2. Nosso API gateway invocará automaticamente a função Lambda correta

6.8. Integration Types

6.8.1. MOCK

6.8.1.1. O API Gateway retorna uma resposta sem enviar a solicitação ao back-end

6.8.2. HTTP / AWS (Lambda & AWS Services)

6.8.2.1. Deve configurar a solicitação de integração e a resposta de integração

6.8.2.2. Configure o mapeamento de dados usando modelos de mapeamento para a solicitação e resposta

6.8.3. AWS_PROXY (Lambda Proxy)

6.8.3.1. A solicitação recebida do cliente é a entrada para o Lambda

6.8.3.2. A função é responsável pela lógica de requisição/resposta

6.8.3.3. Nenhum modelo de mapeamento, cabeçalhos, parâmetros de string de consulta... são passados como argumentos

6.8.4. HTTP_PROXY

6.8.4.1. Nenhum modelo de mapeamento

6.8.4.2. A solicitação HTTP é passada para o back-end

6.8.4.3. A resposta HTTP do back-end é encaminhada pelo API Gateway

6.9. Mapping Templates

6.9.1. Os modelos de mapeamento podem ser usados para modificar solicitações/respostas

6.9.2. Renomear/modificar parâmetros de string de consulta

6.9.3. Modifique o conteúdo do corpo, adicione cabeçalhos

6.10. Caching API responses

6.10.1. O armazenamento em cache reduz o número de chamadas feitas ao back-end

6.10.2. O TTL (tempo de vida) padrão é de 300 segundos, (min: 0s, max: 3600s)

6.10.3. Os caches são definidos por estágio

6.10.4. Possível substituir as configurações de cache por método

6.10.5. Opção de criptografia de cache, capacidade entre 0,5 GB e 237 GB

6.11. Cache Invalidation

6.11.1. Capaz de liberar todo o cache (invalidar) imediatamente

6.11.2. Os clientes podem invalidar o cache com o cabeçalho: Cache-Control: max-age=0 (withproper IAM authorization)

6.11.3. Se você não impor uma política InvalidateCache (ou escolher a opção Exigir caixa de seleção de autorização no console), qualquer cliente pode invalidar o cache da API

6.12. Usage Plans & API Keys

6.12.1. Se você deseja disponibilizar uma API como oferta ($) para seus clientes

6.12.2. Tipos

6.12.2.1. Usage Plan

6.12.2.1.1. quem pode acessar um ou mais estágios e métodos de API implantados

6.12.2.1.2. quanto e com que rapidez eles podem acessá-los

6.12.2.1.3. usa chaves de API para identificar clientes de API e medir o acesso

6.12.2.1.4. configurar limites de limitação e limites de cota que são aplicados em clientes individuais

6.12.2.2. API Keys

6.12.2.2.1. valores de sequência alfanumérica para distribuir aos seus clientes

6.12.2.2.2. Pode usar com planos de uso para controlar o acesso

6.12.2.2.3. Os limites de limitação são aplicados às chaves de API

6.12.2.2.4. Limites de cotas é o número total de solicitações máximas

6.13. Security – Summary

6.13.1. IAM

6.13.1.1. Ótimo para usuários/funções que já estão em sua conta da AWS, + política de recursos para contas cruzadas

6.13.1.2. Lidar com autenticação + autorização, aproveita a assinatura v4

6.13.2. Custom Authorizer

6.13.2.1. Ótimo para tokens de terceiros

6.13.2.2. Muito flexível em termos de qual política IAM é retornada

6.13.2.3. Lidar com verificação de autenticação + autorização na função Lambda

6.13.2.4. Pagamento por invocação do Lambda, os resultados são armazenados em cache

6.13.3. Cognito User Pool

6.13.3.1. Ótimo para tokens de terceiros

6.13.3.2. Muito flexível em termos de qual política IAM é retornada

6.13.3.3. Lidar com verificação de autenticação + autorização na função Lambda

6.13.3.4. Pagamento por invocação do Lambda, os resultados são armazenados em cache

6.14. HTTP API vs REST API

6.14.1. HTTP

6.14.1.1. proxy AWS Lambda econômico e de baixa latência, APIs de proxy HTTP e integração privada (sem mapeamento de dados)

6.14.1.2. suporta autorização OIDC e OAuth 2.0 e suporte integrado para CROS

6.14.1.3. Sem planos de uso e chaves de API

6.14.2. REST

6.14.2.1. Todos os recursos (exceto Native OpenID Connect / OAuth 2.0)

6.15. WebSocket API

6.15.1. Comunicação interativa bidirecional entre o navegador de um usuário e um servidor

6.15.2. O servidor pode enviar informações para o cliente

6.15.3. Isso permite casos de uso de aplicativos com estado

6.15.4. São frequentemente usadas em aplicativos de tempo real, como aplicativos de bate-papo, plataformas de colaboração, jogos multijogador e plataformas de negociação financeira.

6.15.5. Funciona com AWS Services (Lambda,DynamoDB) ou endpoints HTTP

6.16. Architecture

6.16.1. Crie uma interface única para todos os microsserviços da sua empresa

6.16.2. Use endpoints de API com vários recursos

6.16.3. Aplique um nome de domínio simples e certificados SSL

6.16.4. Pode aplicar regras de encaminhamento e transformação no nível do API Gateway

7. Cognito

7.1. User Pools

7.1.1. Funcionalidade de login para usuários do aplicativo

7.1.2. Integre com API Gateway e Application Load Balancer

7.1.3. Crie um banco de dados de usuário sem servidor para seus aplicativos da Web e móveis

7.1.4. O Cognito tem uma IU de autenticação hospedada que você pode adicionar ao seu aplicativo para lidar com fluxos de trabalho de inscrição e entrada

7.1.5. Usando a IU hospedada, você tem uma base para integração com logins sociais, OIDC ou SAML

7.1.6. Pode personalizar com um logotipo personalizado e CSS personalizado

7.2. Identity Pools

7.2.1. Forneça credenciais da AWS aos usuários para que eles possam acessar os recursos da AWS diretamente

7.2.2. Integre-se com o Cognito User Pools como um provedor de identidade

7.2.3. Obtenha identidades para “usuários” para que eles obtenham credenciais temporárias da AWS

7.2.4. Os usuários podem acessar os serviços da AWS diretamente ou por meio do API Gateway

7.2.5. Identidades autenticadas do desenvolvedor (servidor de login personalizado)

7.2.6. Cognito Identity Pools permite acesso não autenticado (convidado)

7.3. Sync

7.3.1. Sincronize os dados do dispositivo com o Cognito.

7.3.2. Está obsoleto e substituído pelo AppSync

7.3.3. Preferências da loja, configuração, estado do aplicativo

7.3.4. Sincronização entre dispositivos (qualquer plataforma – iOS, Android, etc…)

7.3.5. Capacidade offline (sincronização quando novamente online)

7.3.6. Armazene dados em conjuntos de dados (até 1 MB), até 20 conjuntos de dados para sincronizar

7.3.7. Push Sync: notifique silenciosamente em todos os dispositivos quando os dados de identidade forem alterados

7.3.8. Cognito Stream: transmita dados do Cognito para o Kinesis

7.3.9. Cognito Events: executa funções do Lambda em resposta a eventos

7.4. VS IAM

7.4.1. Funções IAM padrão para usuários autenticados e convidados

7.4.2. Defina regras para escolher a função de cada usuário com base no ID do usuário

7.4.3. Você pode particionar o acesso de seus usuários usando variáveis de política

7.4.4. As credenciais do IAM são obtidas pelo Cognito Identity Pools por meio do STS

7.4.5. As funções devem ter uma política de “confiança” de Cognito Identity Pools

7.5. Cognito User Pools vs Identity Pools

7.5.1. User Pools

7.5.1.1. Banco de dados de usuários para seu aplicativo web e móvel

7.5.1.2. Permite federar logins através de Public Social, OIDC, SAML…

7.5.1.3. Pode personalizar a interface do usuário hospedada para autenticação (incluindo o logotipo)]

7.5.1.4. Possui gatilhos com AWS Lambda durante o fluxo de autenticação

7.5.2. Identity Pools

7.5.2.1. Obtenha credenciais da AWS para seus usuários

7.5.2.2. Os usuários podem fazer login por meio dos grupos de usuários Public Social, OIDC, SAML e Cognito

7.5.2.3. Os usuários podem ser não autenticados (convidados)

7.5.2.4. Os usuários são mapeados para funções e políticas do IAM, podem aproveitar variáveis de política

8. Security & Encryption

8.1. O KMS armazena a CMK e recebe dados dos clientes, os quais criptografa e envia de volta

8.2. Encryption in flight (SSL)

8.2.1. Os dados são criptografados antes do envio e descriptografados após o recebimento

8.2.2. Certificados SSL ajudam com criptografia (HTTPS)

8.2.3. A criptografia durante o voo garante que nenhum MITM (man in the middle attack) aconteça

8.3. Server side encryption at rest

8.3.1. Os dados são criptografados após serem recebidos pelo servidor

8.3.2. Os dados são descriptografados antes de serem enviados

8.3.3. É armazenado de forma criptografada graças a uma chave (geralmente uma chave de dados)

8.3.4. As chaves de criptografia/descriptografia devem ser gerenciadas em algum lugar e o servidor deve ter acesso a elas

8.4. Client side encryption

8.4.1. Os dados são criptografados pelo cliente e nunca descriptografados pelo servidor

8.4.2. Os dados serão descriptografados por um cliente receptor

8.4.3. O servidor não deve ser capaz de descriptografar os dados

8.4.4. Poderia aproveitar a criptografia de envelope

8.5. AWS KMS

8.5.1. Sempre que você ouvir “criptografia” para um serviço da AWS, é mais provável que seja KMS

8.5.2. A AWS gerencia as chaves de criptografia para nós

8.5.3. Totalmente integrado com IAM para autorização

8.5.4. Maneira fácil de controlar o acesso aos seus dados

8.5.5. Capaz de auditar o uso da chave KMS usando CloudTrail

8.5.6. Perfeitamente integrado à maioria dos serviços da AWS (EBS, S3, RDS, SSM…)

8.5.7. Nunca guarde seus segredos em texto simples, especialmente em seu código!

8.5.8. KMS Key Encryption também disponível por meio de chamadas de API (SDK, CLI)

8.5.9. Segredos criptografados podem ser armazenados no código/variáveis de ambiente

8.6. Keys Types

8.6.1. KMS Keys é o novo nome da KMS Customer Master Key

8.6.2. Symmetric (AES-256 keys)

8.6.2.1. Chave de criptografia única usada para criptografar e descriptografar

8.6.2.2. Os serviços da AWS integrados ao KMS usam CMKs simétricas

8.6.2.3. Você nunca obtém acesso à chave KMS não criptografada (deve chamar a API KMS para usar)

8.6.3. Asymmetric (RSA & ECC key pairs)

8.6.3.1. Par público (criptografar) e chave privada (descriptografar)

8.6.3.2. Usado para criptografar/descriptografar ou assinar/verificar operações

8.6.3.3. A chave pública pode ser baixada, mas você não pode acessar a chave privada não criptografada

8.6.3.4. Caso de uso: criptografia fora da AWS por usuários que não podem chamar a API KMS

8.7. AWS KMS (Key Management Service)

8.7.1. Três tipos de chaves KMS:

8.7.1.1. AWS Managed Key: grátis (aws/service-name, exemplo: aws/rds ou aws/ebs)

8.7.1.2. Chaves gerenciadas pelo cliente (CMK) criadas no KMS: $ 1 / mês

8.7.1.3. Chaves gerenciadas pelo cliente importadas (devem ser chaves simétricas de 256 bits): $ 1 / mês

8.7.2. + pagar por chamada de API para KMS (US$ 0,03 / 10.000 chamadas)

8.7.3. Automatic Key rotation

8.7.3.1. Chave KMS gerenciada pela AWS

8.7.3.1.1. automática a cada 1 ano

8.7.3.2. Chave KMS gerenciada pelo cliente

8.7.3.2.1. (deve ser habilitada) automática a cada 1 ano

8.7.3.3. Chave KMS importada

8.7.3.3.1. somente rotação manual possível usando alias

8.8. KMS Key Policies

8.8.1. Controle o acesso a chaves KMS, “semelhantes” às políticas de bucket do S3

8.8.2. Diferença: você não pode controlar o acesso sem eles

8.8.3. Tipos

8.8.3.1. Default KMS Key Policy

8.8.3.1.1. Criado se você não fornecer uma política de chave KMS específica

8.8.3.1.2. Acesso completo à chave para o usuário root = toda a conta da AWS

8.8.3.2. Custom KMS Key Policy

8.8.3.2.1. Definir usuários, funções que podem acessar a chave KMS

8.8.3.2.2. Defina quem pode administrar a chave

8.8.3.2.3. Útil para acesso entre contas de sua chave KMS

8.9. Envelope Encryption

8.9.1. A chamada da API KMS Encrypt tem um limite de 4 KB

8.9.2. Se você deseja criptografar > 4 KB, precisamos usar Envelope Encryption

8.9.3. A API principal que nos ajudará é a API GenerateDataKey

8.9.4. Para o exame: qualquer coisa com mais de 4 KB de dados que precise ser criptografada deve usar Envelope Encryption == GenerateDataKey API

8.10. KMS Symmetric – API Summary

8.10.1. Criptografar: criptografe até 4 KB de dados por meio do KMS

8.10.2. GenerateDataKey

8.10.2.1. Gera uma chave de dados simétrica exclusiva (DEK)

8.10.2.2. Retorna uma cópia em texto simples da chave de dados

8.10.2.3. E uma cópia criptografada na CMK que você especificar

8.10.3. GenerateDataKeyWithoutPlaintext

8.10.3.1. Gere um DEK para usar em algum momento (não imediatamente)

8.10.3.2. DEK que é criptografado sob a CMK que você especifica (deve usar Decrypt mais tarde)

8.10.4. Decrypt

8.10.4.1. descriptografar até 4 KB de dados (incluindo chaves de criptografia de dados)

8.10.5. GenerateRandom

8.10.5.1. Retorna uma string de bytes aleatórios

8.11. KMS Request Quotas

8.11.1. Quando você excede uma cota de solicitação, recebe uma ThrottlingException

8.11.2. Para responder, use a retirada exponencial (retirada e nova tentativa)

8.11.3. Para operações criptográficas, eles compartilham uma cota

8.11.4. Isso inclui solicitações feitas pela AWS em seu nome (ex: SSE-KMS)

8.11.5. Para GenerateDataKey, considere usar o cache de DEK do Encryption SDK

8.11.6. Você pode solicitar um aumento de cotas de solicitação por meio da API ou do suporte da AWS

8.12. SSM Parameter Store

8.12.1. Armazenamento seguro para configuração e segredos

8.12.2. Criptografia contínua opcional usando KMS

8.12.3. SDK sem servidor, escalável, durável e fácil

8.12.4. Rastreamento de versão de configurações/segredos

8.12.5. Segurança através do IAM

8.12.6. Notificações com Amazon EventBridge

8.12.7. Integração com CloudFormation

8.13. AWS Secrets Manager

8.13.1. Serviço mais recente, destinado a armazenar segredos

8.13.2. Capacidade de forçar a rotação de segredos a cada X dias

8.13.3. Geração automatizada de segredos em rotação (usa Lambda)

8.13.4. Integração com Amazon RDS (MySQL, PostgreSQL, Aurora)

8.13.5. Os segredos são criptografados usando o KMS

8.13.6. Principalmente destinado à integração RDS

8.14. SSM Parameter Store vs Secrets Manager

8.14.1. Secrets Manager ($$$)

8.14.1.1. Rotação automática de segredos com AWS Lambda

8.14.1.2. A função Lambda é fornecida para RDS, Redshift, DocumentDB

8.14.1.3. A criptografia KMS é obrigatória

8.14.1.4. Pode integração com CloudFormation

8.14.2. SSM Parameter Store ($)

8.14.2.1. API simples

8.14.2.2. Nenhuma rotação secreta (pode ativar a rotação usando o Lambda acionado por CW Events)

8.14.2.3. A criptografia KMS é opcional, pode ser integrada ao CloudFormation

8.14.2.4. Pode extrair um segredo do Secrets Manager usando a API SSM Parameter Store

9. EC2

9.1. Instancias

9.1.1. Zonais

9.1.1.1. É uma instância reservada zonal fornece uma reserva de capacidade na zona de disponibilidade especificada

9.1.1.2. As reservas de capacidade permitem que você reserve capacidade para suas instâncias do Amazon EC2 em uma zona de disponibilidade específica por qualquer duração.

9.1.1.3. Oferece capacidade de criar e gerenciar Reservas de Capacidade independentemente dos descontos de cobrança oferecidos pelos Savings Plans ou Instâncias Reservadas regionais

9.1.1.4. Você não pode enfileirar compras para instâncias reservadas zonais.

9.1.2. Regional

9.1.2.1. O desconto da Instância reservada se aplica ao uso da instância em qualquer zona de disponibilidade na região especificada.

9.1.2.2. É possível enfileirar compras para instâncias reservadas regionais.

10. Dicas

10.1. Simultaneidade provisionada

10.1.1. Para permitir que sua função seja dimensionada sem flutuações na latência

10.1.2. Inicializa um número solicitado de ambientes de execução para que eles estejam preparados para responder imediatamente às invocações da sua função. Observe que a configuração da simultaneidade provisionada incorre em cobranças na sua conta da AWS

10.2. Lambda

10.2.1. Aliases Lambda

10.2.1.1. É como um ponteiro para uma versão específica da função do Lambda. Os usuários podem acessar a versão da função usando o alias ARN

10.2.2. Com ALB

10.2.2.1. Usar grupo de destino

10.2.3. Simultaneidade reservada

10.2.3.1. É deduzida da capacidade geral da conta da AWS em uma determinada região. A função Lambda sempre tem a simultaneidade reservada disponível exclusivamente para suas próprias invocações.

10.2.3.2. Limita a simultaneidade máxima para a função e se aplica à função como um todo, incluindo versões e aliases

10.2.3.3. Garante o número máximo de instâncias simultâneas para a função. Quando uma função tem simultaneidade reservada, nenhuma outra função pode usar essa simultaneidade. Não há cobrança para configurar a simultaneidade reservada para uma função

10.3. Variáveis ​​de Estágio

10.3.1. São pares nome-valor que você pode definir como atributos de configuração associados a um estágio de implantação de uma API

10.4. CodeDeploy

10.4.1. Arquivo buildspec.yml no diretorio raiz

10.4.2. Deployment

10.4.2.1. In place / No local

10.4.2.1.1. Atualiza as instâncias existentes do EC2

10.4.2.1.2. EC2 recém-criadas por um ASG também receberão implantações automatizadas

10.4.2.1.3. Implantações do Lambda e do ECS não podem usar um tipo de implantação in-loco

10.4.2.2. Blue/Green

10.4.2.2.1. Novo ASG é criado

10.4.2.2.2. Deve estar usando um ELB

10.4.2.2.3. Escolha por quanto tempo manter as instâncias antigas do EC2 (antigo ASG)

10.5. Dependencias

10.5.1. CodeBuild

10.5.1.1. Reduz o tempo de compilação armazenando em cache as dependências no S3 (NAO PARA O Elastic Beanstalk)

10.5.2. CodePipeline

10.5.2.1. Agrupe as dependências no código-fonte no BeanStalk

10.6. CodePipeline

10.6.1. Não pode ser configurado com um gatilho para o Lambda

10.7. AppSpec vs Buildspec

10.7.1. AppSpec

10.7.1.1. Mapeie os arquivos de origem na revisão do aplicativo para seus destinos na instância.

10.7.1.2. Especifique permissões personalizadas para arquivos implantados.

10.7.1.3. Especifique os scripts a serem executados em cada instância em vários estágios do processo de implantação.

10.7.2. Buildspec

10.7.2.1. É um arquivo usado pelo AWS CodeBuild para executar uma compilação

10.8. Beanstalk

10.8.1. "Implantar a próxima versão com MÍNIMO tempo de inatividade do aplicativo e a capacidade de reverter rapidamente caso a implantação dê errado"

10.8.1.1. Implantação blue/Green com Route 53

10.8.2. Lote adicional

10.8.2.1. Implanta a nova versão, certificando-se de que o desempenho e a disponibilidade não sejam afetados

10.8.3. Imutaveis

10.8.3.1. Dados perdidos

10.8.3.2. reverter rapidamente

10.8.4. Rolando

10.8.4.1. Algumas instâncias atendem solicitações com a versão antiga, enquanto outras instâncias atendem solicitações da nova versão até a implementação seja concluída

10.8.4.2. Sem custos adicionais

10.8.5. Tudo de uma vez

10.8.5.1. você gostaria de implantar rapidamente e não se preocupar com o tempo de inatividade

10.8.6. Questoes

10.8.6.1. Garanti que a capacidade total das instâncias utilizadas

10.8.6.1.1. Imutavel

10.8.6.1.2. Rolando com maquinas adicionais

10.8.6.1.3. Divisao de trafego

10.8.6.2. parte dos servidores ficam indisponíveis enquanto a implantação é feita

10.8.6.2.1. Continua

10.8.6.3. Na verde/azul e imutável os ambientes são duplicados antes do direcionamento do tráfego.

10.9. SQS

10.9.1. EC2 leva cerca de 20 segundos, em média, para processar cada arquivo de gravação bruto / impedir mesma filmagem bruta não seja processada por vários consumidores

10.9.1.1. Usar ChangeMessageVisibility

10.9.2. Tempo de visibilidade padrão é 30s

10.10. S3

10.10.1. SSE-SE

10.10.1.1. AES256

10.10.2. SSE-KMS

10.10.2.1. 'AWS:KMS'

10.10.2.2. Envio de objetos HTTP

10.10.3. SSE-C

10.10.3.1. A solicitação será rejeitada se a conexão não estiver usando HTTPS

10.10.3.2. operações PUT, GET, Head e Copy

10.10.4. Criptografia no lado do cliente

10.10.4.1. Chaves de criptografia precisam ser gerenciadas por uma equipe de segurança interna, mas a própria chave é armazenada na AWS

10.10.5. enviar seus objetos por HTTP

10.10.5.1. 'criptografia do lado do servidor x-amz': 'aws:kms'

10.11. CloudFormation

10.11.1. Dependencias é uma seção invalida

10.11.2. As condições não podem ser usadas na seção Parâmetros

10.11.3. Conjunto de operações

10.11.3.1. visualizar um resumo das alterações propostas em uma pilha

10.11.4. Stackset

10.11.4.1. usados ​​para criar, atualizar ou excluir pilhas em várias contas e regiões com uma única operação

10.11.5. Drift Connection

10.11.5.1. é usado para detectar quando uma configuração se desvia da configuração do modelo

10.12. KMS

10.12.1. O KMS armazena a CMK e recebe dados dos clientes, os quais criptografa e envia de volta

10.13. EC2

10.13.1. X-Ray sampling

10.13.1.1. Quando funciona o rastreamento local e nao funciona no EC2, isso não ajuda a determinar a causa da falha

10.13.2. Daemon do EC2 X-Ray

10.13.2.1. É um aplicativo de software que detecta o tráfego na porta UDP 2000, reúne dados brutos do segmento e os retransmite para a API do AWS X-Ray

10.14. DynamoDB

10.14.1. Formulas

10.14.1.1. Um app grava 12 itens por segundo em uma tabela do DynamoDB, com cada item com 8 KB de tamanho

10.14.1.1.1. 12 * (8 KB / 1 KB) = 96 WCU.

10.14.1.2. Um app fazendo leituras Fortemente Consistentes de 10 itens por segundo, com cada item com 10 KB de tamanho.

10.14.1.2.1. 10 * (12 KB / 4 KB) = 30 RCU

10.14.1.3. Um app fazendo leituras EVENTUALMENTE consistentes de 12 itens por segundo, com cada item com 16 KB de tamanho.

10.14.1.3.1. 12 * (16 KB / 4 KB) = 48 / 2 = 24 RCU.

10.14.2. BatchGetItem

10.14.2.1. Precisa ler até 100 itens por vez, cada item tem até 100 KB de tamanho e todos os atributos devem ser recuperados

10.14.3. utilizar consultas eventualmente consistentes

10.14.3.1. 50%

10.14.4. Otimização na performance de RCU se você alterar as leituras para eventualmente consistentes As leituras dos dados são transacionais

10.14.4.1. 75%

10.15. Redes

10.15.1. Latencia

10.15.1.1. Metrica do tempo de resposta entre api gateway e cliente

10.15.2. limite de falha

10.15.2.1. Parametro que o Route 53 define se um endpoint esta integro

10.16. CloudWatch

10.16.1. Insights

10.16.1.1. Não pode criar métrica personalizada

10.17. ECS

10.17.1. AfterInstall

10.17.1.1. Use para executar tarefas depois que o conjunto de tarefas de substituição for criado e um dos grupos de destino for associado a ele.

10.17.2. BeforeInstall

10.17.2.1. Use para executar tarefas antes que o conjunto de tarefas de substituição seja criado. Um grupo de destino é associado ao conjunto de tarefas original.

10.17.3. AfterAllowTestTraffic

10.17.3.1. Use para executar tarefas depois que o listener de teste distribuir o tráfego para o conjunto de tarefas de substituição.

10.17.4. BeforeAllowTraffic

10.17.4.1. Use para executar tarefas depois que o segundo grupo de destino for associado ao conjunto de tarefas de substituição, mas antes que o tráfego seja deslocado para o conjunto de tarefas de substituição.

10.17.5. AfterAllowTraffic

10.17.5.1. Use para executar tarefas depois que o segundo grupo de destino distribuir o tráfego para o conjunto de tarefas de substituição.

10.17.6. Lambda

10.17.6.1. Implantações

10.17.6.1.1. Linear

10.17.6.1.2. Canario

10.17.6.1.3. All at once

11. ElasticCache

11.1. Replicação

11.1.1. Cluster Mode Disabled

11.1.1.1. Um nó primário, até 5 réplicas. Replicação Assíncrona

11.1.1.2. O nó primário é usado para leitura/gravação. Os outros nós são somente leitura

11.1.1.3. Um fragmento, todos os nós têm todos os dados

11.1.1.4. Proteção contra perda de dados em caso de falha do nó

11.1.1.5. Multi-AZ ativado por padrão para failover. Útil para dimensionar o desempenho de leitura

11.1.2. Cluster Mode Enabled

11.1.2.1. Os dados são particionados em estilhaços (útil para escalar gravações)

11.1.2.2. Cada shard tem um primário e até 5

11.1.2.3. Nós de réplica (mesmo conceito de antes) Recurso Multi-AZ

11.1.2.4. Até 500 nós por cluster

11.2. Lazy Loading / Cache-Aside / Lazy Population

11.2.1. Pros

11.2.1.1. Apenas os dados solicitados são armazenados em cache (o cache não é preenchido com dados não utilizados)

11.2.1.2. Falhas de nó não são fatais (apenas aumento da latência para aquecer o cache)

11.2.2. Contras

11.2.2.1. Penalidade de falta de cache que resulta em 3 viagens de ida e volta, atraso perceptível para essa solicitação

11.2.2.2. Dados obsoletos: os dados podem ser atualizados no banco de dados e desatualizados no cache

11.3. Write Through

11.3.1. Pros

11.3.1.1. Os dados no cache nunca ficam obsoletos, as leituras são rápidas

11.3.1.2. Penalidade de gravação vs penalidade de leitura (cada gravação requer 2 chamadas)

11.3.2. Contras

11.3.2.1. Faltam Dados até que sejam adicionados/atualizados no BD. A mitigação é implementar a estratégia Lazy Loading também

11.3.2.2. Churn de cache – muitos dados nunca serão lidos

12. CLI/SDK/IAM Roles and Policy

12.1. Dry run

12.1.1. Testa a crição do recurso a seco e não executa toda a ação

12.2. STS Decode Errors

12.2.1. Quando você executa chamadas de API e elas falham, você pode receber uma longa mensagem de erro

12.2.2. Esta mensagem de erro pode ser decodificada usando a linha de comando STS: sts decode-authorization-message

12.3. Metadata

12.3.1. Metadata = Informações da EC2 instance

12.3.2. Userdata = Roda scripts no EC2 instance

12.3.3. Ele permite que as instâncias do AWS EC2 “aprendam sobre si mesmas” sem usar uma função do IAM para essa finalidade.

12.4. MFA with CLI

12.4.1. Deve criar uma sessão temporária deve executar a chamada API STS GetSessionToken

12.5. AWS Limits

12.5.1. API Rate Limits

12.5.1.1. A API DescribeInstances para EC2 tem um limite de 100 chamadas por segundo

12.5.1.2. GetObject no S3 tem um limite de 5500 GET por segundo por prefixo

12.5.1.3. Para erros intermitentes: implemente recuo exponencial

12.5.1.3.1. Se obtiver ThrottlingException intermitentemente, use backoff exponencial

12.5.1.3.2. Mecanismo de repetição já incluído nas chamadas de API do AWS SDK

12.5.1.3.3. Deve implementar você mesmo se estiver usando a API da AWS como está ou em casos específicos

12.5.1.3.4. Só deve implementar as novas tentativas em erros de servidor 5xx e limitação. Erros 4xx não deve ser implementado

12.5.1.4. Para erros consistentes: solicite um aumento do limite de limitação da API

12.5.2. Service Quotas

12.5.2.1. Executando instâncias padrão sob demanda: 1.152 vCPU

12.5.2.2. Você pode solicitar um aumento de limite de serviço abrindo um ticket

12.5.2.3. Você pode solicitar um aumento de cota de serviço usando a API de cotas de serviço

13. CloudFront

13.1. Multiple Origin

13.1.1. Rotear para diferentes tipos de origens com base no tipo de conteúdo

13.1.2. Com base no padrão de caminho: /images, /api

13.2. Origin Groups

13.2.1. Para aumentar a alta disponibilidade e fazer failover

13.2.2. Grupo de origem: uma origem primária e uma secundária Se a origem primária falhar, a segunda é usada

14. Docker, ECS, ECR, Fargate

14.1. ECS Rolling Updates

14.1.1. Ao atualizar de v1 para v2, podemos controlar quantas tarefas podem ser iniciadas e interrompidas e em qual ordem

14.2. ECS Task Definitions

14.2.1. São metadados no formato JSON para informar ao ECS como executar um contêiner do Docker

14.2.2. Pode definir até 10 contêineres em uma definição de tarefa

14.3. ECS Task Placement

14.3.1. Quando uma tarefa do ECS é iniciada com EC2 Launch Type, o ECS deve determinar onde colocá-la, com as restrições de CPU e memória (RAM)

14.3.2. Quando um serviço escala, o ECS precisa determinar qual tarefa encerrar

14.3.3. Task Placement Process

14.3.3.1. São um melhor esforço

14.3.3.1.1. 1. Identifique quais instâncias atendem aos requisitos de CPU, memória e porta

14.3.3.1.2. 2. Identifique quais instâncias atendem às Restrições de Colocação de Tarefas

14.3.3.1.3. 3. Identifique quais instâncias atendem às Estratégias de Colocação de Tarefas

14.3.3.1.4. 4. Selecione as instâncias

14.3.4. Task Placement Strategy

14.3.4.1. Binpack

14.3.4.1.1. As tarefas são colocadas na menor quantidade disponível de CPU e memória

14.3.4.1.2. Minimiza o número de instâncias do EC2 em uso (economia de custos)

14.3.4.2. Random

14.3.4.2.1. As tarefas são colocadas aleatoriamente

14.3.4.3. Spread

14.3.4.3.1. As tarefas são colocadas uniformemente com base no valor especificado

14.3.4.4. É possivel mistura-los

14.3.5. Task Placement Constraints

14.3.5.1. distinctInstance

14.3.5.1.1. As tarefas são colocadas em uma instância EC2 diferente

14.3.5.2. memberOf

14.3.5.2.1. As tarefas são colocadas em instâncias do EC2 que atendem a uma expressão especificada

14.3.5.2.2. Usa a linguagem de consulta de cluster (avançado)

15. Elastic Beanstalk

15.1. Componentes

15.1.1. Application, Application version e Environment

15.1.2. Env: Coleção de recursos da AWS executando uma versão do aplicativo (somente uma versão do aplicativo por vez)

15.1.3. Tiers: Web Server Environment Tier (ALB, ELB, ASG) & Worker Environment Tier (Worker, SQS)

15.2. Deployments

15.2.1. Modes

15.2.1.1. Alta disponibilidade com balanceador de carga Ótimo para prod

15.2.1.2. Single Instance otimo para DEV

15.2.2. Options for Updates

15.2.2.1. All at once

15.2.2.1.1. (Implantar tudo de uma vez) – mais rápido, mas as instâncias não estão disponíveis para atender ao tráfego por um tempo (tempo de inatividade)

15.2.2.1.2. Implementação mais rápida, o aplicativo tem tempo de inatividade, ótimo para iterações rápidas em um ambiente de desenvolvimento, sem custo adicional

15.2.2.2. Rolling

15.2.2.2.1. Atualize algumas instâncias por vez (bucket) e, em seguida, passe para o próximo bucket assim que o primeiro bucket estiver íntegro

15.2.2.2.2. O aplicativo está sendo executado abaixo da capacidade, Pode definir o tamanho do bucket, O aplicativo está executando as duas versões simultaneamente, Sem custo adicional, Implantação longa

15.2.2.3. Rolling with additional batches

15.2.2.3.1. Como rolar, mas ativa novas instâncias para mover o lote (para que o aplicativo antigo ainda esteja disponível)

15.2.2.3.2. O aplicativo está sendo executado na capacidade máxima, Pode definir o tamanho do bucket, O aplicativo está executando ambas as versões, simultaneamente, Pequeno custo adicional, Lote adicional é removido no final da implantação, Implantação mais longa, Bom para produção

15.2.2.3.3. Implantar uma versão, certificando-se de que o desempenho e a disponibilidade não sejam afetados.

15.2.2.3.4. Adequada se precisa manter a mesma largura de banda durante a implantação

15.2.2.4. Immutable

15.2.2.4.1. Gira novas instâncias em um novo ASG, implanta a versão para essas instâncias e, em seguida, troca todas as instâncias quando tudo está íntegro

15.2.2.4.2. instâncias em um ASG temporário, alto custo, capacidade dupla, implantação mais longa, reversão rápida em caso de falhas (basta encerrar o novo ASG), ótimo para produção

15.2.2.5. Blue Green

15.2.2.5.1. Crie um novo ambiente e troque quando estiver pronto

15.2.2.5.2. Não é um “recurso direto” do Elastic Beanstalk, tempo de inatividade zero e facilidade de lançamento, cria um novo ambiente de “estágio” e implante a v2 lá. O novo ambiente (verde) pode ser validado independentemente e revertido se houver problemas

15.2.2.5.3. O Route 53 pode ser configurado usando políticas ponderadas para redirecionar um pouco do tráfego para o ambiente de palco. Usando o Beanstalk, “trocar URLs” quando terminar com o teste de ambiente

15.2.2.6. Traffic Splitting

15.2.2.6.1. Teste canário – envie uma pequena porcentagem do tráfego para uma nova implantação

15.2.2.6.2. A nova versão do aplicativo é implantada em um ASG temporário com a mesma capacidade. Uma pequena porcentagem do tráfego é enviada para o ASG temporário por um período de tempo configurável

15.2.2.6.3. A integridade da implantação é monitorada, se houver uma falha na implantação, isso aciona uma reversão automática (muito rápida) Sem tempo de inatividade do aplicativo, novas instâncias são migradas do temporário para o original ASG A versão antiga do aplicativo é encerrada

15.2.3. Lifecycle Policy

15.2.3.1. O Elastic Beanstalk pode armazenar no máximo 1.000 versões de aplicativos, se você não remover as versões antigas, não poderá mais implantar, para eliminar versões antigas de aplicativos, use uma política de ciclo de vida

15.2.3.2. Com base no tempo (versões antigas foram removidas)

15.2.3.3. Com base no espaço (quando você tem muitas versões)

15.2.3.4. As versões usadas atualmente não serão excluídas

15.2.3.5. Opção de não excluir o pacote de origem no S3 para evitar perda de dados

15.2.4. Extensions

15.2.4.1. Todos os parâmetros definidos na interface do usuário podem ser configurados com código usando arquivos

15.2.4.2. no diretório .ebextensions/ na raiz do código-fonte no formato YAML/JSON

15.2.4.3. extensões .config (exemplo: logging.config)

15.2.4.4. Capaz de modificar algumas configurações padrão usando: option_settings

15.2.4.5. Capacidade de adicionar recursos como RDS, ElastiCache, DynamoDB, etc…

15.2.4.6. Os recursos gerenciados por .ebextensions são excluídos se o ambiente for desativado

15.2.5. Migration: Load Balancer

15.2.5.1. Depois de criar um ambiente Elastic Beanstalk, não é possível alterar o tipo do Elastic Load Balancer (somente a configuração)

15.2.5.2. Migrar:

15.2.5.2.1. 1. crie um novo ambiente com a mesma configuração, exceto LB (não pode clonar)

15.2.5.2.2. 2. implante seu aplicativo no novo ambiente

15.2.5.2.3. 3. execute uma troca de CNAME ou atualização do Route 53

15.2.6. RDS with Elastic Beanstalk

15.2.6.1. RDS pode ser provisionado com Beanstalk, o que é ótimo para desenvolvimento/teste

15.2.6.2. Isso não é bom para prod, pois o ciclo de vida do banco de dados está vinculado ao ciclo de vida do ambiente Beanstalk

15.2.6.3. O melhor para prod é criar separadamente um banco de dados RDS e fornecer ao nosso aplicativo EB a string de conexão

15.2.7. Migração de contas

15.2.7.1. Deve usar configurações salvas para migrar um ambiente do Elastic Beanstalk entre contas da AWS

15.2.7.2. Salve a configuração do seu ambiente como um objeto no Amazon Simple Storage Service (Amazon S3) que pode ser aplicado a outros ambientes durante a criação do ambiente ou aplicado a um ambiente em execução

16. DinamoDB

16.1. Primary Keys

16.1.1. Option 1: Partition Key (HASH)

16.1.1.1. A chave de partição deve ser exclusiva para cada item

16.1.1.2. A chave de partição deve ser “diversa” para que os dados sejam distribuídos

16.1.1.3. Exemplo: “User_ID” para uma tabela de usuários

16.1.2. Option 2: Partition Key + Sort Key (HASH + RANGE)

16.1.2.1. A combinação deve ser única para cada item

16.1.2.2. Os dados são agrupados por chave de partição

16.1.2.3. Exemplo: tabela users-games, “User_ID” para Partition Key e “Game_ID” para Sort Key

16.2. Read/Write Capacity Modes

16.2.1. Você pode alternar entre modos diferentes uma vez a cada 24 horas

16.2.2. Tipos

16.2.2.1. Provisioned Mode (default)

16.2.2.1.1. Você especifica o número de leituras/gravações por segundo

16.2.2.1.2. Você precisa planejar a capacidade com antecedência

16.2.2.1.3. Pague por unidades de capacidade de leitura e gravação provisionadas

16.2.2.1.4. A taxa de transferência pode ser excedida temporariamente usando “Burst Capacity”

16.2.2.1.5. Se a capacidade de explosão foi consumida, você receberá um “ProvisionedThroughputExceededException”

16.2.2.1.6. Em seguida, é aconselhável fazer uma nova tentativa de retirada exponencial

16.2.2.1.7. Uma unidade de capacidade de gravação (WCU) representa uma gravação por segundo para um item de até 1 KB de tamanho

16.2.2.2. On-Demand Mode

16.2.2.2.1. A leitura/gravação aumenta/diminui automaticamente com suas cargas de trabalho

16.2.2.2.2. Não é necessário planejamento de capacidade

16.2.2.2.3. Pague pelo que usar, mais caro ($$$)

16.3. Strongly vs. Eventually Consistent Read

16.3.1. Eventually Consistent Read (default)

16.3.1.1. Se lermos logo após uma gravação, é possível que obter alguns dados obsoletos por causa da replicação

16.3.2. Strongly Consistent Read

16.3.2.1. Se lermos logo após uma gravação, obteremos os dados corretos

16.3.2.2. Defina o parâmetro “ConsistentRead” como True em Chamadas de API (GetItem, BatchGetItem, Query, Scan)

16.3.2.3. Consome o dobro da RCU

16.3.3. Uma unidade de capacidade de leitura (RCU) representa uma leitura fortemente consistente por segundo, ou duas leituras eventualmente consistentes por segundo, para um item de até 4 KB de tamanho

16.3.4. Se os itens forem maiores que 4 KB, mais RCUs serão consumidas

16.3.5. Formulas

16.3.5.1. Um app grava 12 itens por segundo em uma tabela do DynamoDB, com cada item com 8 KB de tamanho

16.3.5.1.1. 12 * (8 KB / 1 KB) = 96 WCU.

16.3.5.2. Um app fazendo leituras Fortemente Consistentes de 10 itens por segundo, com cada item com 10 KB de tamanho.

16.3.5.2.1. 10 * (12 KB / 4 KB) = 30 RCU

16.3.5.3. Um app fazendo leituras eventualmente consistentes de 12 itens por segundo, com cada item com 16 KB de tamanho.

16.3.5.3.1. 12 * (16 KB / 4 KB) = 48 / 2 = 24 RCU.

16.4. Local Secondary Index (LSI)

16.4.1. Chave de classificação alternativa para sua tabela (mesma chave de partição da tabela base)

16.4.2. A chave de classificação consiste em um atributo escalar (string, número ou binário)

16.4.3. Até 5 Índices Secundários Locais por tabela

16.4.4. Deve ser definido no momento da criação da tabela

16.4.5. Projeções de atributos – podem conter alguns ou todos os atributos da tabela base (KEYS_ONLY, INCLUDE, ALL)

16.4.6. Vc cria Query usando um atributo que NÃO faz parte da chave primária da sua tabela. Vc usa o >=predicado enquanto mantém a mesma chave de partição

16.5. Global Secondary Index (GSI)

16.5.1. Chave primária alternativa (HASH ou HASH+RANGE) da tabela base

16.5.2. Acelerar consultas em atributos não-cha

16.5.3. A chave de índice consiste em atributos escalares (string, número ou binário)

16.5.4. Projeções de Atributos – alguns ou todos os atributos da tabela base (KEYS_ONLY, INCLUDE, ALL)

16.5.5. Deve fornecer RCUs e WCUs para o índice

16.5.6. Pode ser adicionado/modificado após a criação da tabela

16.5.7. Vc cria Query no DynamoDB usando um atributo que NÃO faz parte da chave primária da sua tabela

16.6. Indexes and Throttling

16.6.1. GSI

16.6.1.1. Se as gravações forem limitadas no GSI, a tabela principal será limitada!

16.6.1.2. Mesmo que o WCU nas mesas principais esteja bom

16.6.1.3. Escolha sua chave de partição GSI com cuidado!

16.6.1.4. Atribua sua capacidade de WCU com cuidado!

16.6.2. LSI

16.6.2.1. Usa as WCUs e RCUs da tabela principal

16.6.2.2. Nenhuma consideração especial de limitação

16.7. PartiQL

16.7.1. SQL no NoSQL

16.8. Optimistic Locking

16.8.1. O DynamoDB tem um recurso chamado “Gravações condicionais”

16.8.2. Uma estratégia para garantir que um item não foi alterado antes de atualizá-lo/excluí-lo

16.8.3. Cada item tem um atributo que atua como um número de versão

16.9. DynamoDB Transactions

16.9.1. Operações coordenadas de tudo ou nada (adicionar/atualizar/excluir) para vários itens em uma ou mais tabelas

16.9.2. Fornece atomicidade, consistência, isolamento e durabilidade (ACID)

16.9.3. Modos de leitura – consistência eventual, consistência forte, transacional

16.9.4. Modos de Gravação – Padrão, Transacional

16.9.5. Consome 2x WCUs e RCUs

17. SAM/CDK

17.1. SAM

17.1.1. Estrutura para desenvolver e implantar aplicativos sem servidor

17.1.2. Toda a configuração é código YAML

17.1.3. Gere CloudFormation complexo a partir de um arquivo SAM YAML simples

17.1.4. Suporta qualquer coisa do CloudFormation: Saídas, Mapeamentos,Parâmetros, Recursos…

17.1.5. Apenas dois comandos para implantar na AWS

17.1.6. O SAM pode usar o CodeDeploy para implantar funções Lambda e executar Lambda, API Gateway, DynamoDB localmente

17.1.7. Recipe

17.1.7.1. Transform Header indicates it’s SAM template: Transform: 'AWS::Serverless-2016-10-31'

17.1.8. Write Code

17.1.8.1. AWS::Serverless::

17.1.8.1.1. Function

17.1.8.1.2. Api

17.1.8.1.3. SimpleTable

17.1.9. Package & Deploy

17.1.9.1. aws cloudformation package / sam package

17.1.9.2. aws cloudformation deploy / sam deploy

17.1.10. A estrutura SAM usa nativamente o CodeDeploy para atualizar as funções do Lambda

17.2. CDK

17.2.1. Defina sua infraestrutura de nuvem usando uma linguagem familiar: JavaScript/TypeScript, Python, Java e .NET

17.2.2. Contém componentes de alto nível chamados construções

17.2.3. O código é “compilado” em um modelo CloudFormation (JSON/YAML)

17.2.4. Você pode, portanto, implantar infraestrutura e código de tempo de execução do aplicativo juntos

17.2.4.1. Ótimo para funções do Lambda e para contêineres do Docker no ECS/EKS

17.3. CDK vs SAM

17.3.1. SAM

17.3.1.1. Focado sem servidor

17.3.1.2. Escreva seu modelo declarativamente em JSON ou YAML

17.3.1.3. Ótimo para começar rapidamente com o Lambda

17.3.1.4. Aproveita o CloudFormation

17.3.2. CDK

17.3.2.1. Todos os serviços da AWS

17.3.2.2. Escreva infra em uma linguagem de programação JavaScript/TypeScript, Python, Java e .NET

17.3.2.3. Aproveita o CloudFormation

18. Serverless Services

18.1. Step Functions

18.1.1. Modele seus fluxos de trabalho como máquinas de estado (uma por fluxo de trabalho)

18.1.2. Escrito em JSON

18.1.3. Visualização do fluxo de trabalho e execução do fluxo de trabalho, bem como histórico

18.1.4. Inicie o fluxo de trabalho com chamada de SDK, API Gateway, Event Bridge (CloudWatch Event)

18.1.5. Task States

18.1.5.1. Faça algum trabalho em sua máquina de estado

18.1.5.2. Invoque um serviço da AWS

18.1.5.3. Execute uma atividade

18.1.6. Step Function - States

18.1.6.1. Choice State

18.1.6.1.1. Teste uma condição para enviar para uma ramificação (ou ramificação padrão)

18.1.6.2. Fail or Succeed State

18.1.6.2.1. Interrompa a execução com falha ou sucesso

18.1.6.3. Pass State

18.1.6.3.1. Simplesmente passe sua entrada para sua saída ou injete alguns dados fixos, sem realizar trabalho

18.1.6.4. Wait State

18.1.6.4.1. Fornece um atraso por um determinado período de tempo ou até uma hora/data especificada.

18.1.6.5. Map State

18.1.6.5.1. Etapas iteradas dinamicamente.

18.1.6.6. Parallel State

18.1.6.6.1. Inicia ramificações paralelas de execução.

18.1.7. Error Handling

18.1.7.1. Use Retry (para repetir o estado com falha) e Catch (transição para o caminho da falha) na máquina de estado para lidar com os erros em vez de dentro do código do aplicativo

18.1.7.2. Error codes

18.1.7.2.1. States.ALL : corresponde a qualquer nome de erro

18.1.7.2.2. States.Timeout: a tarefa foi executada por mais de TimeoutSeconds ou nenhuma pulsação foi recebida

18.1.7.2.3. States.TaskFailed: falha na execução

18.1.7.2.4. States.Permissions: privilégios insuficientes para executar o código

18.1.7.3. Retry

18.1.7.3.1. Avaliado de cima para baixo

18.1.7.3.2. ErrorEquals: corresponde a um tipo específico de erro

18.1.7.3.3. IntervalSeconds: atraso inicial antes de tentar novamente

18.1.7.3.4. BackoffRate: multiplique o atraso após cada nova tentativa

18.1.7.3.5. MaxAttempts: padrão para 3, definido como 0 para nunca tentar novamente

18.1.7.3.6. Quando o máximo de tentativas é atingido, o Catch entra em ação

18.1.7.4. Catch

18.1.7.4.1. Avaliado de cima para baixo

18.1.7.4.2. ErrorEquals: corresponde a um tipo específico de erro

18.1.7.4.3. Seguinte: Estado para onde enviar

18.1.7.4.4. ResultPath - Um caminho que determina qual entrada é enviada para o estado especificado no campo Próximo.

18.2. AppSync

18.2.1. AppSync é um serviço gerenciado que usa GraphQL

18.2.2. O GraphQL torna mais fácil para os aplicativos obter exatamente os dados de que precisam.

18.2.3. Isso inclui combinar dados de uma ou mais fontes

18.2.4. Recupere dados em tempo real com WebSocket ou MQTT no WebSocket

18.2.5. Para aplicativos móveis: acesso a dados locais e sincronização de dados

18.2.6. Tudo começa com o upload de um esquema GraphQL

18.2.7. Security

18.2.7.1. Há quatro maneiras de autorizar aplicativos a interagir com sua API GraphQL do AWS AppSync

18.2.7.1.1. CHAVE API

18.2.7.1.2. AWS_IAM: usuários/funções/acesso entre contas do IAM

18.2.7.1.3. OPENID_CONNECT: Provedor OpenID Connect / JSON Web Token

18.2.7.1.4. AMAZON_COGNITO_USER_POOLS

18.3. Amplify

18.3.1. Conjunto de ferramentas para começar a criar aplicativos móveis e da web “Elastic Beanstalk para aplicativos móveis e da web”

18.3.2. Recursos obrigatórios, como armazenamento de dados, autenticação, armazenamento e aprendizado de máquina, todos desenvolvidos pelos serviços da AWS

18.3.3. Bibliotecas front-end com componentes prontos para uso para React.js, Vue, Javascript, iOS, Android, Flutter, etc…

18.3.4. Incorpora as melhores práticas da AWS para confiabilidade, segurança e escalabilidade

18.3.5. Crie e implemente com o Amplify CLI ou o Amplify Studio

18.3.6. Features

18.3.6.1. AUTHENTICATION

18.3.6.1.1. Aproveita o Amazon Cognito

18.3.6.1.2. Registro de usuário, autenticação, recuperação de conta e outras operações

18.3.6.1.3. Suporta MFA, login social, etc…

18.3.6.1.4. Componentes de IU pré-construídos

18.3.6.1.5. Autorização refinada

18.3.6.2. DATASTORE

18.3.6.2.1. Aproveita o Amazon AppSync e o Amazon DynamoDB

18.3.6.2.2. Trabalhe com dados locais e tenha sincronização automática com a nuvem sem códigos complexos

18.3.6.2.3. Desenvolvido por GraphQL

18.3.6.2.4. Recursos offline e em tempo real

18.3.6.2.5. Modelagem de dados visuais com Amplify Studio

18.4. AWS Directory Services

18.4.1. AWS Managed Microsoft AD

18.4.1.1. Crie seu próprio AD na AWS, gerencie usuários localmente, suporte MFA

18.4.1.2. Estabeleça conexões de “confiança” com seu AD local

18.4.2. AD Connector

18.4.2.1. Gateway de diretório (proxy) para redirecionar para AD local, suporta MFA

18.4.2.2. Os usuários são gerenciados no AD local

18.4.3. Simple AD

18.4.3.1. Diretório gerenciado compatível com AD na AWS

18.4.3.2. Não pode ser associado ao AD local

19. IAM

19.1. Access Advisor no console do IAM

19.1.1. Pode usar informações para identificar, analisar e remover com confiança as funções não utilizadas

19.2. Políticas baseadas em recursos

19.2.1. Politica de confiança

19.3. IAM Access Analyzer

19.3.1. Ajuda identificar os recursos em sua organização e contas

19.4. AWS Billing and Cost Management

19.4.1. Você precisa ativar o acesso de usuário do IAM ao console do Billing and Cost Management para todos os usuários que precisam de acesso