Un processo di web-crawling viene eseguito su un parco istanze EC2 t2.micro. Le istanze interrogano una coda SQS di URL di destinazione, eseguono il crawling di ciascun URL in 10 secondi o meno e scrivono i risultati su un file system Amazon EFS condiviso montato su ogni istanza. Gli URL vengono aggiunti alla coda raramente e le metriche mostrano che le istanze rimangono inattive quando la coda è vuota. È necessario riprogettare per l'ottimizzazione dei costi. Quali due modifiche insieme sono le più convenienti?

Le istanze t2.micro rimangono inattive quando la coda SQS è vuota, indicando un utilizzo inefficiente delle risorse. Rifattorizzare il processo in una funzione AWS Lambda è conveniente perché Lambda è serverless e si paga solo per il tempo di calcolo effettivo utilizzato, eliminando i costi per l'inattività. Lambda può essere configurata per elaborare i messaggi SQS su richiesta. L'archiviazione dei risultati su Amazon EFS comporta costi per lo storage e il throughput. Spostare l'archiviazione su Amazon S3 è più conveniente perché S3 offre storage a oggetti a basso costo, scalabilità elevata e durabilità, ed è ideale per archiviare grandi volumi di dati non strutturati come i risultati di un web-crawling. Sostituire le istanze t2.micro con m5.8xlarge aumenterebbe i costi, anche con una riduzione del parco istanze, poiché le istanze m5.8xlarge sono molto più costose e sovradimensionate per un'attività che è spesso inattiva. L'uso di Amazon Neptune o Aurora Serverless MySQL per i risultati sarebbe più costoso e complesso rispetto a S3, in quanto sono database relazionali o a grafo, non ottimizzati per l'archiviazione di dati non strutturati di grandi dimensioni.