APRENDER. PRATICAR. EVOLUIR.Separar os intervenientes e permissões
O produtor que publica no tópico, o serviço SNS que entrega à fila e o consumidor que recebe e elimina mensagens executam ações diferentes. Para permitir um tópico específico, a política da fila pode autorizar sqs:SendMessage ao serviço SNS com condição aws:SourceArn igual ao ARN desse tópico. Não confundas a autorização de Publish no tópico com a de SendMessage na fila. Um consumidor simples pode precisar apenas de ReceiveMessage, ChangeMessageVisibility e DeleteMessage sobre a fila indicada, conforme o fluxo descrito. Outras operações da implementação devem ser inventariadas separadamente. Evita usar sqs:* para esconder a falta de diagnóstico. Testa também a recusa de uma origem ou ação fora do requisito.
Incluir as chaves na recuperação
Permissão para ler uma fila não demonstra permissão para decifrar os dados necessários. Numa DLQ com mensagens cifradas nas origens, identifica as chaves que protegeram essas mensagens e confirma kms:Decrypt para o consumidor nas condições aplicáveis. A chave atual da DLQ não deve ser assumida como a única dependência de todas as mensagens antigas. Trata políticas de identidade e da chave em conjunto e mantém o âmbito mínimo adequado. Não apagues uma chave apenas porque a aplicação de origem foi retirada: mensagens, cópias ou outros dados podem continuar dependentes dela. A revisão operacional deve ligar o inventário de dados retidos ao inventário de chaves, responsáveis e condições de recuperação.
Diagnosticar filtros e falhas de entrega
Um filtro SNS avalia o âmbito configurado. Se procura kind em MessageBody mas o produtor só o envia como atributo, a ausência no corpo explica a não correspondência. Alterações à política podem demorar até 15 minutos a propagar; planeia verificação que distinga propagação de erro de contrato. Noutra camada, EventBridge tem limites de tempo e tentativas para entrega ao alvo. Uma DLQ de alvo captura falhas de entrega quando corretamente autorizada; não é a mesma coisa que a DLQ do consumidor após receber trabalho. Se a associação for feita pela API, confirma a política de recurso que permite sqs:SendMessage a EventBridge e restringe a regra de origem.
Calcular capacidade líquida
Uma fila absorve diferenças temporárias entre chegada e conclusão, mas não cria capacidade no destino. Num modelo constante com 450 mensagens por segundo a chegar e 600 a concluir, a redução líquida é 150 por segundo. Um backlog de 9000 demora 60 segundos a desaparecer, assumindo ausência de retries e outros limites. Dividir por 600 daria 15 segundos e ignoraria o trabalho novo. Se cada execução mantém uma ligação e só há orçamento de 40 ligações, propor 100 execuções concorrentes viola esse pressuposto. Mede débito útil, idade do trabalho e comportamento do destino. Quotas e capacidade real exigem verificação própria; os números aqui são sintéticos e não medições AWS.
Reduzir trabalho e pedidos desnecessários
Long polling pode reduzir respostas vazias e responder quando há mensagens disponíveis, até ao limite configurado. Ajusta também o timeout HTTP do cliente para não interromper a espera prevista. Num modelo vazio de 60 segundos, uma chamada por segundo produz 60 pedidos; três esperas completas de 20 segundos produzem três. A redução de 95% pertence a esse modelo, não a uma previsão garantida da fatura. Respostas parciais também podem reduzir trabalho repetido: num lote de dez com duas falhas, repetir apenas essas duas evita oito processamentos já concluídos. Custos reais dependem de chamadas, duração, tamanho, tráfego e configuração. Compara alternativas com a mesma garantia de recuperação e resultado de negócio.
Resumo: validar o percurso completo
Constrói uma tabela do percurso: produtor, tópico ou regra, autorização de entrega, fila, consumidor, chave, efeito e reconhecimento. Para cada fronteira, regista falha observável, dono e recuperação. Um dashboard de mensagens recebidas não prova que o efeito final terminou. Uma DLQ vazia também não prova ausência de falhas se a entrega à própria DLQ está sem autorização. Nos exercícios, usa entradas conhecidas para verificar filtros, permissões e conjuntos de repetição; depois compara resultados esperados e obtidos. Estes modelos locais ensinam decisões e permitem testar cálculos, mas não validam um ambiente AWS real. Mantém explícitas as hipóteses antes de transformar uma conta de capacidade ou custo numa decisão operacional.
Backlog de 9000, chegadas de 450/s e conclusões de 600/s: redução líquida de 150/s e 60 segundos no modelo constante.
Armadilhas comuns
Confundir Publish com SendMessage, DLQ de entrega com falha de consumo, instalação de permissões com teste ou concorrência com débito útil.
Tópicos relacionados: Eventos e desacoplamento · Identidade e permissões
O desenho só é operacionalmente útil quando entrega, autorização, capacidade, custo e recuperação correspondem ao mesmo resultado esperado.
Referência: SAA-C03 performance objectives · SAA-C03