Un'azienda di media gestisce un sito pubblico di notizie e video su AWS. Il sito mantiene un indice dei metadati video in una tabella Amazon DynamoDB configurata con capacità provisionata e i file video stessi risiedono in un bucket Amazon S3. Durante un evento ad alto traffico, le letture sulla tabella DynamoDB sono state limitate (throttled) e i video non sono stati visualizzati. Gli operatori hanno aumentato temporaneamente e manualmente la capacità di lettura provisionata della tabella. Il team desidera essere avvisato prima che si verifichi un throttling in futuro. È stato creato un argomento Amazon SNS e l'email degli operatori è stata iscritta. Quale azione dovrebbe intraprendere il team per soddisfare questo requisito?

L'opzione corretta è creare un allarme Amazon CloudWatch che monitori la metrica ConsumedReadCapacityUnits e impostare la soglia a un livello prossimo alla capacità di lettura provisionata. Questo avviserà il team quando l'utilizzo delle letture si avvicina al limite, permettendo di intervenire prima che si verifichi il throttling. Le ConsumedReadCapacityUnits riflettono l'utilizzo effettivo, mentre le ThrottledReadEvents indicano che il throttling è già avvenuto. Abilitare l'auto scaling di DynamoDB risolverebbe il problema del throttling, ma l'obiettivo della domanda è essere avvisati prima che si verifichi, non solo risolverlo automaticamente. Inoltre, le regole di EventBridge per lo scaling non sono l'approccio diretto per le notifiche preventive. Le opzioni che coinvolgono CloudWatch Logs per THROTTLINGEXCEPTION sono meno efficaci perché queste eccezioni indicano che il throttling è già avvenuto, non che sta per accadere. L'obiettivo è la prevenzione.