Ein Amazon Redshift-Cluster (mit reservierten Knoten) erlebt intermittierende CPU-intensive Bursts durch komplexe Leseabfragen, während ein Team eine detaillierte Überprüfung durchführt. Der Cluster muss jederzeit Lese- und Schreibabfragen bedienen. Welche Option bietet die erforderliche Burst-Kapazität auf die KOSTENGÜNSTIGSTE Weise?

Concurrency Scaling ist die kostengünstigste Option, da es automatisch zusätzliche Cluster-Kapazität bereitstellt, wenn die Abfragelast steigt, und nur für die tatsächlich genutzte Zeit abgerechnet wird. Dies ist ideal für intermittierende Bursts. Ein Amazon EMR-Cluster wäre eine separate Datenverarbeitungsumgebung, die zusätzliche Kosten und Verwaltung mit sich bringt. Eine klassische Größenänderung des Redshift-Clusters erfordert Ausfallzeiten und ist für intermittierende Bursts nicht geeignet. Eine elastische Größenänderung ist zwar schneller, aber immer noch eine dauerhafte Kapazitätserhöhung, die teurer wäre als Concurrency Scaling für temporäre Bursts.