Serverless in pratica: rilevamento di anomalie con AWS Lambda e Amazon Bedrock

Nel panorama API‑first, picchi di latenza, errori 5xx e pattern di traffico sospetti emergono senza preavviso. In questo articolo vedremo come costruire un rilevatore automatico di anomalie in modo economico e scalabile con servizi serverless AWS e un foundation model su Amazon Bedrock, senza addestrare modelli personalizzati.

Obiettivo

Più in dettaglio, il rilevatore avrà lo scopo di analizzare finestre brevi di log di API Gateway (es. 5 minuti), calcolare metriche chiave (percentili di latenza, tassi 4xx/5xx, frequenze per IP/endpoint), inviare un riepilogo compatto a un modello su Bedrock (es. AWS Nova Micro) e registrare/notificare le anomalie. Il risultato è un rilevamento proattivo con sforzo operativo minimo.

Architettura e funzionamento

Servizi AWS utilizzati:

• CloudWatch Logs: raccolta dei log (Detailed logs e Data Tracing).
• EventBridge: invocazione periodica della funzione di analisi.
• Lambda: aggregazione metriche, costruzione prompt, interpretazione risposta.
• Bedrock (AWS Nova Micro): evidenziazione anomalie dal riepilogo.
• DynamoDB: persistenza eventi e metadati.

()[/images/blog/ai_logs_analyzer.webp]

Il flusso è periodico e leggero. I log dettagliati di API Gateway in CloudWatch includono tempi di risposta, codici di stato, IP, endpoint e user‑agent. EventBridge scandisce l’analisi (tipicamente ogni 5 minuti, ma regolabile). Alla chiamata, Lambda interroga i log dell’ultima finestra e aggrega: p50/p95/p99, tassi 4xx/5xx, frequenze per IP/endpoint e pattern ricorrenti. L’aggregazione riduce il volume e aumenta la densità informativa, evitando di inviare log grezzi al modello.

Il riepilogo compatto, con un minimo di baseline (valori medi degli ultimi intervalli), viene inviato a Bedrock. Un modello come AWS Nova Micro è ideale per batch brevi e mirati: individua deviazioni rilevanti (picchi di latenza, esplosioni di 5xx, accessi anomali a specifici endpoint, ripetizioni dallo stesso IP) e restituisce un responso sintetico.

Le anomalie vengono salvate in DynamoDB per storicizzazione e reporting; l’intero ciclo resta serverless, elastico e a basso sforzo di gestione.

Perché non serve addestrare un modello

Con i foundation models di Bedrock è sufficiente uno snapshot ben strutturato: il modello mette in evidenza picchi di latenza, aumenti improvvisi di errori, pattern ripetitivi e deviazioni di volume. Lo sforzo si sposta dal training al design del prompt e dell’estrazione delle feature operative.

Costi e ottimizzazioni

Tutti i servizi sono pay‑per‑use, con zero costi a riposo. Un modello compatto come AWS Nova Micro mantiene bassi i costi per batch brevi. Si può ridurre ulteriormente la spesa regolando la frequenza (cron), limitando il prompt all’essenziale e introducendo soglie locali che inviano a Bedrock solo se necessario. Per riferimento ecco i prezzi dei modelli Bedrock: Amazon Bedrock.

Limiti e considerazioni

I foundation models vedono solo ciò che fornisce il prompt: selezione feature e baseline sono decisive. Per requisiti hard‑real‑time, sarebbe da valutare una pipeline streaming e modelli locali specializzati.

Conclusioni

Un rilevatore di anomalie basato su servizi serverless e foundation models su AWS richiede poca infrastruttura, scala in modo elastico e ha un profilo di costo prevedibile. Aggregando metriche dai log di API Gateway e sfruttando un modello come AWS Nova Micro su Amazon Bedrock, è possibile intercettare degradi e pattern sospetti in minuti, con effort di implementazione contenuto e senza addestrare modelli ML personalizzati.