1. MQ
1.1. Definição
1.1.1. serviço gerenciado de mensageria compatível com Apache ActiveMQ e RabbitMQ, permitindo a comunicação assíncrona entre sistemas distribuídos.
1.2. O que faz
1.2.1. Facilita a troca de mensagens entre aplicações e microsserviços.
1.2.2. Garante entrega confiável e ordenada de mensagens.
1.2.3. Reduz a sobrecarga operacional ao gerenciar a infraestrutura do broker.
1.3. Características
1.3.1. Compatibilidade
1.3.1.1. Suporta ActiveMQ e RabbitMQ, permitindo a migração sem necessidade de grandes mudanças no código.
1.3.2. Alta disponibilidade
1.3.2.1. Pode ser configurado com failover automático e replicação em múltiplas AZs.
1.3.3. Gerenciado
1.3.3.1. Atualizações, provisionamento e manutenção automática pela AWS.
1.3.4. Segurança
1.3.4.1. Suporte a IAM, VPC, TLS e criptografia de mensagens.
1.3.5. Escalabilidade
1.3.5.1. Ajuste de capacidade conforme demanda.
1.4. Quando usar
1.4.1. Quando precisa migrar mensageria existente baseada em ActiveMQ ou RabbitMQ para a AWS.
1.4.2. Para aplicações que exigem alta disponibilidade e resiliência na entrega de mensagens.
1.4.3. Quando deseja reduzir a complexidade operacional de gerenciar um broker de mensagens.
1.4.4. Para conectar sistemas desacoplados em arquiteturas baseadas em eventos.
2. EventBridge
2.1. Definição
2.1.1. serviço de barramento de eventos totalmente gerenciado que facilita a conexão de aplicativos com dados de uma variedade de fontes, incluindo aplicativos internos, aplicativos SaaS e serviços da AWS.
2.2. Quando usar
2.2.1. recebe eventos de diferentes fontes (como AWS, serviços de terceiros ou aplicativos personalizados) e os transmite para destinos configurados (como AWS Lambda, Step Functions, SQS, entre outros).
2.2.2. Permite a criação de fluxos de trabalho baseados em eventos em tempo real.
2.3. O que faz
2.3.1. Escalabilidade automática
2.3.1.1. Processa milhões de eventos por segundo.
2.3.2. Filtros e roteamento avançado
2.3.2.1. Permite criar regras para rotear eventos com base em seu conteúdo.
2.3.3. Fontes de eventos
2.3.3.1. Pode receber eventos de mais de 90 aplicativos SaaS e serviços da AWS.
2.3.4. Integração nativa com AWS Lambda
2.3.4.1. Permite executar funções Lambda em resposta aos eventos.
2.3.5. Suporte a eventos em tempo real
2.3.5.1. Garante uma resposta rápida a eventos gerados em tempo real.
2.4. Características
2.4.1. Automação de fluxos de trabalho
2.4.1.1. Quando você precisa automatizar a resposta a eventos gerados em outros sistemas, como quando um arquivo é carregado em um bucket S3 e precisa ser processado.
2.4.2. Integração de aplicações
2.4.2.1. Para integrar múltiplos sistemas, sejam eles internos ou de terceiros, sem a necessidade de infraestrutura complexa.
2.4.3. Microservices
2.4.3.1. Quando estiver construindo aplicações baseadas em microserviços e precisar de comunicação assíncrona entre esses serviços.
3. Step Functions
3.1. Definição
3.1.1. serviço que permite coordenar múltiplos serviços da AWS em fluxos de trabalho (workflows) visuais e automáticos.
3.1.2. Ele facilita a criação de aplicativos distribuídos, ao orquestrar e gerenciar estados de execução e interações entre diversos serviços de forma escalável e resiliente.
3.2. O que faz
3.2.1. Orquestração de fluxo de trabalho
3.2.1.1. Permite coordenar várias funções em um único fluxo de trabalho.
3.2.2. Escalabilidade
3.2.2.1. Escala automaticamente, dependendo da carga de trabalho.
3.2.3. Resiliência
3.2.3.1. Possui tratamento de falhas integrado, como tentativas automáticas e rastreamento.
3.2.4. Visibilidade
3.2.4.1. Oferece visualização de workflows com o AWS Management Console.
3.2.5. Fácil integração
3.2.5.1. Integra-se com vários serviços AWS como Lambda, SNS, SQS, entre outros.
3.2.6. Modelos de execução
3.2.6.1. Suporta fluxos sequenciais, paralelos, condicionais e baseados em erro.
3.2.7. Padrão de execução
3.2.7.1. Permite a execução de "state machines" com base em JSON.
3.3. Características
3.3.1. Orquestração de tarefas complexas
3.3.1.1. Quando há a necessidade de coordenar múltiplos serviços AWS de forma sequencial ou paralela.
3.3.2. Automatização de processos empresariais
3.3.2.1. Para automatizar fluxos de trabalho que dependem de diferentes serviços.
3.3.3. Aplicações distribuídas
3.3.3.1. Quando é necessário gerenciar a execução de vários componentes em uma arquitetura distribuída.
3.3.4. Gerenciamento de falhas e retries
3.3.4.1. Quando há a necessidade de controlar falhas e realizar tentativas automáticas de execução.
3.3.5. Processamento de tarefas assíncronas
3.3.5.1. Para orquestrar tarefas que não requerem uma resposta imediata ou que envolvem múltiplos passos.
3.4. Quando usar
3.4.1. organiza as tarefas em uma sequência de estados definidos, realizando o gerenciamento da execução de cada estado.
3.4.2. Pode orquestrar tarefas entre funções do AWS Lambda, instâncias EC2, SNS, SQS, e outros serviços da AWS, tornando mais fácil criar aplicações complexas de maneira eficiente e com visibilidade de todo o processo.
4. AppFlow
4.1. Definição
4.1.1. serviço totalmente gerenciado que permite a movimentação de dados de forma simples entre aplicativos SaaS (Software como Serviço) e sistemas AWS, sem a necessidade de codificação.
4.2. O que faz
4.2.1. Facilita a integração de dados entre fontes de dados como Salesforce, ServiceNow, Google Analytics, entre outros, e serviços da AWS, como S3, Redshift, e others.
4.2.2. Possibilita a transferência bidirecional de dados, permitindo tanto a ingestão quanto a exportação de informações de forma segura e escalável.
4.3. Características
4.3.1. Integração sem código
4.3.1.1. Oferece uma interface intuitiva que permite configurar fluxos de dados sem necessidade de escrever código.
4.3.2. Conectores pré-integrados
4.3.2.1. Suporte para diversos aplicativos SaaS populares e serviços da AWS.
4.3.3. Segurança
4.3.3.1. Usa criptografia de dados em trânsito e repouso, oferecendo conformidade com as melhores práticas de segurança.
4.3.4. Orquestração de fluxos
4.3.4.1. Permite criar fluxos de dados programados ou acionados por eventos, com controle total sobre como e quando os dados são transferidos.
4.4. Quando usar
4.4.1. Quando você precisa mover dados entre aplicativos SaaS e a AWS de forma simples e sem escrever código.
4.4.2. Para integrar fontes de dados de terceiros com o AWS, como transferir dados de marketing de ferramentas como Google Analytics para Amazon Redshift para análise.
4.4.3. Quando precisar de uma solução de integração com controle de dados, sem se preocupar com a manutenção de infraestrutura de integração.
5. AppSync
5.1. Definição
5.1.1. serviço gerenciado que facilita a criação de APIs GraphQL, permitindo que você se conecte a fontes de dados, como bancos de dados, APIs REST, e outros serviços, de maneira eficiente e em tempo real.
5.2. Quando usar
5.2.1. Cria e gerencia APIs GraphQL.
5.2.2. Integra dados de diversas fontes, como bancos de dados DynamoDB, Lambda, Elasticsearch e APIs RESTful.
5.2.3. Fornece recursos para otimização de consultas, como caching, e escalabilidade automática.
5.2.4. Oferece suporte a assinaturas em tempo real, permitindo atualizações instantâneas de dados para os clientes.
5.3. O que faz
5.3.1. GraphQL
5.3.1.1. Facilita a consulta de dados de forma flexível, permitindo que o cliente peça exatamente o que precisa.
5.3.2. Escalabilidade
5.3.2.1. A AWS gerencia automaticamente a escalabilidade do serviço.
5.3.3. Assinaturas em Tempo Real
5.3.3.1. Suporte para dados em tempo real via WebSockets.
5.3.4. Segurança
5.3.4.1. Integra-se com AWS Identity and Access Management (IAM) para controle de acesso e autenticação.
5.3.5. Caching
5.3.5.1. Melhora o desempenho com cache automático de respostas.
5.3.6. Fácil Integração
5.3.6.1. Integra-se facilmente com outros serviços AWS, como Lambda, DynamoDB, e Elasticsearch.
5.4. Características
5.4.1. Quando precisar de uma API GraphQL flexível para manipulação de dados em tempo real.
5.4.2. Para criar aplicativos com necessidades de dados em tempo real (como chats, dashboards ao vivo, jogos online).
5.4.3. Quando você quiser otimizar o desempenho de consultas complexas, agregando fontes de dados diversas e cacheando resultados.
5.4.4. Quando precisar integrar diferentes fontes de dados (bancos de dados, serviços de microserviços, etc.) em uma API unificada.
6. SQS
6.1. Definição
6.1.1. serviço de filas de mensagens gerenciado que permite a comunicação assíncrona entre componentes distribuídos, desacoplando serviços e melhorando a escalabilidade e a resiliência das aplicações.
6.2. O que faz
6.2.1. Permite a transmissão de mensagens entre aplicações sem a necessidade de conexão direta.
6.2.2. Garante entrega confiável das mensagens entre serviços.
6.2.3. Suporta processamento assíncrono e desacoplamento de microsserviços.
6.2.4. Oferece duas modalidades de fila: Standard Queue (entrega múltipla de mensagens, ordem não garantida) e FIFO Queue (entrega única, ordenada).
6.3. Características
6.3.1. Totalmente gerenciado
6.3.1.1. não exige administração de infraestrutura.
6.3.2. Escalável
6.3.2.1. pode processar milhões de mensagens por segundo.
6.3.3. Alta disponibilidade e durabilidade
6.3.3.1. replicação em múltiplas zonas de disponibilidade.
6.3.4. Criptografia
6.3.4.1. suporte a criptografia em repouso (SSE) e em trânsito (TLS).
6.3.5. Mensagens com tempo de vida (TTL)
6.3.5.1. permite definir um tempo máximo para retenção das mensagens (até 14 dias).
6.3.6. Visibilidade da mensagem
6.3.6.1. tempo durante o qual uma mensagem fica "invisível" após ser lida, evitando processamento duplicado.
6.4. Fila Padrão
6.4.1. o que faz
6.4.1.1. Desacoplamento de aplicações
6.4.1.1.1. O SQS é usado para desacoplar componentes de aplicações, permitindo que eles se comuniquem de forma assíncrona.
6.4.2. atributos
6.4.2.1. Limitação de tamanho
6.4.2.1.1. Cada mensagem pode ter no máximo 256 KB.
6.4.2.2. Baixa latência
6.4.2.2.1. A latência para publicar e receber mensagens é inferior a 10 ms.
6.4.2.3. Retenção padrão de mensagens
6.4.2.3.1. As mensagens são retidas por 4 dias por padrão, podendo ser configuradas para até 14 dias.
6.4.2.4. Número ilimitado de mensagens na fila
6.4.2.4.1. Não há limite para o número de mensagens que podem ser armazenadas.
6.4.2.5. Taxa de transferência ilimitada
6.4.2.5.1. O SQS pode lidar com um número ilimitado de mensagens por segundo.
6.4.3. observações
6.4.3.1. Mensagens fora de ordem
6.4.3.1.1. As mensagens podem não ser entregues na ordem em que foram enviadas.
6.4.3.2. Mensagens duplicadas
6.4.3.2.1. Pode ocorrer a entrega de mensagens duplicadas.
6.5. Quando usar
6.5.1. Quando há necessidade de comunicação assíncrona entre serviços.
6.5.2. Para desacoplar microsserviços e permitir escalabilidade independente.
6.5.3. Para distribuir cargas de trabalho de forma eficiente, evitando sobrecarga em aplicações.
6.5.4. Quando é necessário garantir a entrega de mensagens sem perda, mesmo que o sistema de destino esteja indisponível temporariamente.
6.5.5. Quando a ordem da mensagem é importante (uso de fila FIFO).
6.6. Etapas
6.6.1. Produzindo Mensagens no SQS
6.6.1.1. o que faz
6.6.1.1.1. Utilização do SDK
6.6.1.1.2. Retenção de Mensagens
6.6.1.2. Atributos e Limitações
6.6.1.2.1. Taxa de Transferência
6.6.1.2.2. Tamanho da Mensagem
6.6.1.3. Sensão
6.6.1.3.1. Message
6.6.1.3.2. Up to 256 kb
6.6.1.4. exemplo de uso
6.6.1.4.1. Um exemplo comum é enviar um pedido para processamento, incluindo detalhes como o ID do pedido, ID do cliente e outros atributos relevantes.
6.6.2. Consumindo Mensagens no SQS
6.6.2.1. Sondagem SQS
6.6.2.1.1. Os consumidores sondam (poll) a fila SQS para receber mensagens. Eles podem receber até 10 mensagens por vez.
6.6.2.2. Consumidores
6.6.2.2.1. Os consumidores podem ser executados em instâncias do Amazon EC2, servidores tradicionais ou como funções do AWS Lambda.
6.6.2.3. Processamento das Mensagens
6.6.2.3.1. Após receber as mensagens, os consumidores as processam. Um exemplo comum é inserir os dados da mensagem em um banco de dados RDS (Relational Database Service).
6.6.2.4. Exclusão das Mensagens
6.6.2.4.1. Após o processamento bem-sucedido, as mensagens são excluídas da fila usando a API DeleteMessage.
6.7. Múltiplas Instâncias EC2 Consumidoras
6.7.1. o que é
6.7.1.1. Consumidores recebem e processam mensagens em paralelo
6.7.1.1.1. Várias instâncias EC2 podem consumir mensagens de uma fila SQS simultaneamente, o que permite o processamento paralelo e aumenta a eficiência.
6.7.2. como funciona
6.7.2.1. Pelo menos uma entrega
6.7.2.1.1. O SQS garante que cada mensagem seja entregue pelo menos uma vez, mas pode haver entregas duplicadas em alguns casos.
6.7.2.2. Ordenação de mensagens de melhor esforço
6.7.2.2.1. O SQS tenta manter a ordem das mensagens, mas não garante a ordenação estrita devido ao processamento paralelo.
6.7.2.3. Consumidores apagam mensagens depois de processá-las
6.7.2.3.1. Após o processamento bem-sucedido, as mensagens são excluídas da fila para evitar reprocessamento.
6.7.2.4. Escalonamento horizontal
6.7.2.4.1. Aumentar o número de instâncias consumidoras pode melhorar a taxa de processamento de mensagens.
6.8. Segurança
6.8.1. Encriptação
6.8.1.1. Criptografia em trânsito: As mensagens são criptografadas durante a transmissão usando a API HTTPS.
6.8.1.2. Criptografia em repouso: As mensagens armazenadas no SQS são criptografadas usando chaves gerenciadas pelo AWS Key Management Service (KMS).
6.8.1.3. Criptografia do lado do cliente: Os clientes podem optar por criptografar e descriptografar as mensagens por conta própria, se necessário.
6.8.2. Controles de Acesso
6.8.2.1. Políticas do IAM: O acesso à API do SQS é regulado por políticas do AWS Identity and Access Management (IAM), que definem permissões detalhadas para usuários e serviços.
6.8.2.2. Políticas de Acesso do SQS: Semelhantes às políticas de bucket do Amazon S3, essas políticas permitem configurar permissões específicas para filas SQS. Elas são úteis para:
6.8.2.2.1. Acesso entre contas: Permitir que contas da AWS diferentes acessem uma fila SQS.
6.8.2.2.2. Integração com outros serviços: Permitir que serviços como Amazon SNS (Simple Notification Service) e Amazon S3 gravem mensagens em uma fila SQS.
6.9. Tempo Limite de Visibilidade da Mensagem
6.9.1. Visibility Timeout
6.9.1.1. Invisibilidade após recebimento: Quando uma mensagem é recebida por um consumidor, ela se torna invisível para outros consumidores por um período específico.
6.9.1.2. Duração padrão: Por padrão, o tempo limite de visibilidade é de 30 segundos. Isso significa que o consumidor tem 30 segundos para processar a mensagem antes que ela se torne visível novamente na fila.
6.9.1.3. Processamento da mensagem: Se a mensagem não for processada e excluída dentro desse período, ela se torna visível novamente e pode ser recebida por outro consumidor.
6.9.2. Reprocessamento de Mensagens
6.9.2.1. Duplicação de mensagens: Se uma mensagem não for processada dentro do tempo limite de visibilidade, ela se tornará visível novamente na fila e poderá ser processada por outro consumidor, resultando em processamento duplicado.
6.9.2.2. Extensão do tempo limite: Um consumidor pode usar a API ChangeMessageVisibility para estender o tempo limite de visibilidade, se necessário, para garantir que a mensagem seja processada sem se tornar visível novamente.
6.9.3. Configuração do Tempo Limite de Visibilidade:
6.9.3.1. Tempo limite alto: Se o tempo limite de visibilidade for configurado para um período longo (horas), e o consumidor falhar, o reprocessamento da mensagem levará mais tempo, pois a mensagem só se tornará visível novamente após o término do tempo limite.
6.9.3.2. Tempo limite baixo: Se o tempo limite de visibilidade for muito curto (segundos), há um risco maior de duplicação de mensagens, pois a mensagem pode se tornar visível novamente antes de ser completamente processada.
6.10. Long Polling
6.10.1. o que é
6.10.1.1. O Long Polling é uma técnica em que o consumidor (cliente) que solicita mensagens da fila SQS espera por um tempo configurável (até 20 segundos) para receber mensagens, caso a fila esteja vazia no momento da solicitação.
6.10.1.2. Isso evita que o consumidor precise fazer várias chamadas de API repetidas (sondagem curta) para verificar se novas mensagens chegaram, o que pode ser ineficiente.
6.10.2. benefícios
6.10.2.1. Redução de chamadas de API: Como o consumidor espera por novas mensagens em vez de fazer várias solicitações em um curto espaço de tempo, o número de chamadas de API é reduzido.
6.10.2.2. Menor latência: Quando uma mensagem chega à fila durante o período de espera, ela é retornada imediatamente ao consumidor, reduzindo a latência no processamento.
6.10.2.3. Eficiência: O Long Polling é mais eficiente em termos de custo e desempenho, especialmente quando a fila pode ficar vazia por períodos prolongados.
6.10.3. configuração
6.10.3.1. Tempo de espera: O tempo de espera pode ser configurado entre 1 segundo e 20 segundos.
6.10.3.2. Um tempo maior (20 segundos) é geralmente preferível, pois maximiza a eficiência.
6.10.3.3. Habilitação: O Long Polling pode ser habilitado de duas formas:
6.10.3.3.1. No nível da fila: Configurando a fila para usar Long Polling por padrão.
6.10.3.3.2. No nível da API: Usando o parâmetro WaitTimeSeconds na chamada da API ReceiveMessage.
6.10.4. Long Polling vs. Short Polling
6.10.4.1. Short Polling: O consumidor faz chamadas frequentes à fila, mesmo quando não há mensagens disponíveis. Isso pode resultar em um grande número de chamadas de API desnecessárias.
6.10.4.2. Long Polling: O consumidor espera por um tempo configurável para receber mensagens, reduzindo o número de chamadas de API e melhorando a eficiência.
6.11. Fila FIFO
6.11.1. First In, First Out
6.11.1.1. o que é
6.11.1.1.1. É um tipo de fila no SQS que garante que as mensagens sejam processadas na ordem em que foram enviadas.
6.11.1.1.2. Isso é crucial para aplicações onde a ordem das mensagens é importante, como em sistemas de processamento de transações financeiras ou sequências de eventos.
6.11.1.2. Taxa de Transferência
6.11.1.2.1. Limitação: A fila FIFO tem uma taxa de transferência menor em comparação com a fila padrão do SQS.
6.11.1.2.2. Essa limitação é um trade-off para garantir a ordenação e a entrega exatamente uma vez.
6.11.1.3. Entrega Exatamente Uma Vez:
6.11.1.3.1. Remoção de duplicatas: A fila FIFO garante que cada mensagem seja processada exatamente uma vez, eliminando duplicatas. Isso é alcançado por meio de um mecanismo de detecção de duplicação baseado em um ID exclusivo (Message Deduplication ID).
6.11.1.3.2. Benefício: Ideal para cenários onde a duplicação de mensagens pode causar problemas, como em sistemas de pagamento ou processamento de pedidos.
6.11.1.4. Ordem de Processamento:
6.11.1.4.1. Mensagens em ordem: As mensagens são processadas na ordem exata em que foram enviadas para a fila. Isso é garantido pelo uso de Message Group ID, que agrupa mensagens relacionadas e as processa em sequência.
6.11.1.4.2. Aplicações: Útil para sistemas que exigem sequenciamento estrito, como processamento de eventos em sequência ou operações que dependem de uma ordem específica.
7. SNS
7.1. Definição
7.1.1. serviço de mensagens totalmente gerenciado que permite a comunicação assíncrona entre sistemas, aplicações e serviços por meio de notificações.
7.1.2. Ele opera com o modelo "Publish/Subscribe"
7.1.2.1. Produtor de eventos (Publisher)
7.1.2.1.1. É a aplicação ou sistema que envia mensagens para um tópico do SNS. Um tópico é como um canal de comunicação.
7.1.2.1.2. O produtor só envia mensagens para um tópico específico.
7.1.2.2. Receptores de eventos (Subscribers)
7.1.2.2.1. São as aplicações ou usuários que se inscrevem em um tópico para receber as mensagens enviadas pelo produtor.
7.1.2.2.2. O slide indica que pode haver quantos assinantes forem necessários.
7.2. O que faz
7.2.1. Envia mensagens e notificações para diversos assinantes em diferentes formatos, como SMS, e-mail, HTTP, ou serviços da AWS como SQS e Lambda.
7.2.2. Suporta o modelo pub/sub (publicação/assinatura), onde um tópico recebe mensagens de publicadores e as distribui para assinantes.
7.2.3. Garante alta disponibilidade e escalabilidade no envio de notificações.
7.3. Características
7.3.1. Comunicação assíncrona baseada em eventos.
7.3.2. Suporte a diferentes protocolos de entrega (HTTP, HTTPS, e-mail, SMS, SQS, Lambda, aplicativos móveis).
7.3.3. Alta disponibilidade e escalabilidade automática.
7.3.4. Permite aplicar filtros de mensagens para que assinantes recebam apenas conteúdos relevantes.
7.3.5. Suporte a mensagens criptografadas e autenticação por IAM para controle de acesso.
7.3.6. Integração com AWS CloudWatch para monitoramento de métricas e alarmes.
7.4. Como funciona
7.4.1. Quando o produtor envia uma mensagem para um tópico, o SNS entrega essa mensagem para todos os assinantes inscritos nesse tópico.
7.4.2. Cada assinante recebe todas as mensagens, mas também destaca que existe um novo recurso para filtrar mensagens, o que permite que os assinantes recebam apenas as mensagens relevantes para eles.
7.4.3. O SNS suporta diversos protocolos de entrega
7.4.4. formas de envio
7.4.4.1. SQS (Simple Queue Service): Para filas de mensagens.
7.4.4.2. Lambda: Para funções serverless.
7.4.4.3. Kinesis Data Firehose: Para streaming de dados.
7.4.4.4. Emails: Para usuários.
7.4.4.5. SMS & Mobile Notifications: Para dispositivos móveis.
7.4.4.6. HTTP/HTTPS Endpoints: Para aplicações web ou servidores.
7.5. Limites
7.5.1. Até 12.500.000 assinaturas por tópico.
7.5.2. Limite de 100.000 tópicos.
7.6. Quando usar
7.6.1. Para enviar notificações em tempo real para usuários ou sistemas (exemplo: alertas de segurança, status de aplicações).
7.6.2. Para distribuir mensagens entre diferentes componentes de uma aplicação distribuída.
7.6.3. Para disparar eventos que ativam funções AWS Lambda ou filas SQS para processamento assíncrono.
7.6.4. Em arquiteturas baseadas em eventos, garantindo comunicação eficiente e desacoplada entre serviços.
7.7. Publicações
7.7.1. Publicação de tópicos (usando o SDK)
7.7.1.1. Criar um tópico
7.7.1.1.1. Um tópico é como um canal de comunicação. Você cria um tópico para agrupar as mensagens que deseja enviar para um conjunto específico de assinantes.
7.7.1.2. Criar uma assinatura (ou várias)
7.7.1.2.1. Uma assinatura é um registro de um assinante em um tópico. Você pode criar várias assinaturas para diferentes tipos de assinantes (por exemplo, e-mail, SMS, aplicativo móvel).
7.7.1.3. Publicar no tópico
7.7.1.3.1. Depois de criar o tópico e as assinaturas, você pode publicar mensagens no tópico. O SNS se encarregará de entregar as mensagens para todos os assinantes inscritos no tópico.
7.7.2. Direct Publish (para SDK de aplicativos móveis)
7.7.2.1. Criar um aplicativo de plataforma
7.7.2.1.1. Você precisa criar um aplicativo de plataforma para cada tipo de plataforma móvel que deseja suportar (por exemplo, iOS, Android).
7.7.2.2. Criar um endpoint de plataforma
7.7.2.2.1. Um endpoint de plataforma é um registro de um dispositivo móvel específico em um aplicativo de plataforma.
7.7.2.3. Publicar no endpoint da plataforma
7.7.2.3.1. Você pode publicar mensagens diretamente para um endpoint de plataforma específico. O SNS se encarregará de entregar a mensagem para o dispositivo móvel correspondente.
7.7.2.4. Funciona com Google GCM, Apple APNS, Amazon ADM...
7.7.2.4.1. O SNS suporta vários serviços de notificação push para dispositivos móveis, incluindo Google Cloud Messaging (GCM), Apple Push Notification Service (APNS) e Amazon Device Messaging (ADM).
7.8. Segurança
7.8.1. Encriptação
7.8.1.1. Criptografia a bordo (em trânsito)
7.8.1.1.1. O SNS utiliza a API HTTPS para criptografar as mensagens durante a transmissão, protegendo-as contra interceptação.
7.8.1.2. Criptografia em repouso
7.8.1.2.1. O SNS permite criptografar as mensagens armazenadas em repouso usando chaves gerenciadas pelo AWS Key Management Service (KMS).
7.8.1.2.2. Isso garante que os dados estejam protegidos mesmo se o armazenamento subjacente for comprometido.
7.8.1.3. Criptografia do lado do cliente
7.8.1.3.1. Se você precisar de controle total sobre a criptografia, pode criptografar as mensagens antes de enviá-las ao SNS e descriptografá-las após recebê-las.
7.8.2. Controles de acesso
7.8.2.1. Políticas do IAM: O AWS Identity and Access Management (IAM) permite controlar o acesso à API do SNS, definindo quem pode criar, publicar, assinar ou excluir tópicos e assinaturas.
7.8.3. Políticas de acesso do SNS: Semelhantes às políticas de bucket do Amazon S3, as políticas de acesso do SNS permitem conceder permissões a outras contas da AWS ou serviços para acessar seus tópicos.
7.8.3.1. Isso é útil para:
7.8.3.1.1. Acesso entre contas
7.8.3.1.2. Permitir que outros serviços escrevam em um tópico
7.9. SNS + SQS = Fan Out
7.9.1. Como funciona
7.9.1.1. Um "produtor" (neste caso, o "Buying Service") envia uma mensagem para um tópico do SNS.
7.9.1.2. O SNS distribui a mensagem para todas as filas SQS que estão inscritas nesse tópico.
7.9.1.3. Cada fila SQS armazena a mensagem até que um "consumidor" (neste caso, o "Fraud Service" e o "Shipping Service") a processe.
7.9.2. Vantagens
7.9.2.1. Desacoplamento: O produtor não precisa conhecer os consumidores. Isso torna o sistema mais flexível e escalável.
7.9.2.2. Confiabilidade: O SQS garante que as mensagens sejam entregues, mesmo se os consumidores estiverem offline ou indisponíveis.
7.9.2.3. Flexibilidade: Você pode adicionar ou remover consumidores a qualquer momento, sem afetar o produtor.
7.9.2.4. Processamento Assíncrono: As mensagens podem ser processadas em paralelo pelos diferentes consumidores.
7.9.2.5. Persistência: O SQS armazena as mensagens até que sejam processadas, garantindo que nenhuma mensagem seja perdida.
7.9.2.6. Tratamento de Falhas
7.9.2.6.1. O SQS permite o processamento atrasado e novas tentativas de trabalho, o que ajuda a lidar com falhas nos consumidores.
7.9.2.7. Cross-Region Delivery
7.9.2.7.1. O SNS pode enviar mensagens para filas SQS em outras regiões da AWS, o que permite criar sistemas distribuídos globalmente.
7.10. Amazon SNS - Tópico FIFO
7.10.1. o que é
7.10.1.1. O Amazon SNS agora oferece tópicos FIFO (First-In-First-Out), que garantem que as mensagens sejam entregues na mesma ordem em que foram publicadas.
7.10.1.2. Isso é crucial para aplicações que dependem da ordem das mensagens, como sistemas de processamento de pedidos ou transações financeiras.
7.10.2. Características Principais
7.10.2.1. Ordenação FIFO: As mensagens são entregues aos assinantes na mesma ordem em que foram publicadas no tópico. Ordenação por ID do Grupo de Mensagens: Você pode agrupar mensagens relacionadas usando um ID de grupo de mensagens. O SNS garante que as mensagens dentro de um grupo sejam entregues em ordem, mas a ordem entre diferentes grupos não é garantida.
7.10.2.2. Eliminação de Duplicação: O SNS oferece duas formas de eliminar mensagens duplicadas:
7.10.2.2.1. ID de Eliminação de Duplicação: Você fornece um ID exclusivo para cada mensagem. O SNS garante que apenas uma mensagem com esse ID seja entregue. Eliminação de Duplicação Baseada em Conteúdo: O SNS calcula um hash do conteúdo da mensagem e usa esse hash para identificar e eliminar mensagens duplicadas.
7.10.2.3. Compatibilidade com Filas SQS: Os tópicos FIFO do SNS podem ter filas SQS Standard e FIFO como assinantes. Isso permite que você escolha o tipo de fila que melhor se adapta às suas necessidades. Taxa de Transferência Limitada: Os tópicos FIFO do SNS têm uma taxa de transferência limitada, que é a mesma do SQS FIFO. Isso se deve à necessidade de garantir a ordenação das mensagens.
7.10.3. Casos de Uso
7.10.3.1. Processamento de pedidos: Garantir que os pedidos sejam processados na ordem em que foram recebidos. Transações financeiras: Garantir que as transações sejam processadas na ordem correta. Log de eventos: Garantir que os eventos sejam registrados na ordem em que ocorreram. Atualizações de estoque: Garantir que as atualizações de estoque sejam aplicadas na ordem correta.
7.11. SNS - Filtragem de Mensagens
7.11.1. o que é
7.11.1.1. O Amazon Simple Notification Service (SNS) permite filtrar mensagens enviadas para assinantes de um tópico, usando políticas JSON.
7.11.1.2. Isso significa que você pode especificar quais mensagens um assinante deve receber com base em atributos da mensagem.
7.11.2. Como funciona
7.11.2.1. Política de Filtro: Você cria uma política JSON que define os critérios de filtragem. A política pode especificar quais atributos da mensagem devem estar presentes e quais valores esses atributos devem ter.
7.11.2.2. Assinatura: Você associa a política de filtro a uma assinatura de um tópico do SNS.
7.11.2.3. Publicação: Quando uma mensagem é publicada no tópico, o SNS avalia a política de filtro de cada assinatura.