AWS T3 Instanzen – Moderner, schneller, günstiger

Am 21. August kündigt Jeff Barr mal eben in einem Blogpost an, dass der neue T3-Instanztyp für EC2 nun in 12 AWS-Regionen verfügbar sei ¹. Durch die cosee-Büros geht ein kurzer Aufschrei der Begeisterung. Denn nach signifikanten Performance-Verlusten auf T2-Instanzen durch Meltdown/Spectre Patches zum Anfang des Jahres ist ein neuer credit-basierter Instanztyp auf einer aktuellen CPU-Architektur schon lange überfällig.

Wieso überhaupt T-Instanzen einsetzen?

Betreibt man eine Microservice Architektur auf AWS (die den Schritt zu Kubernetes noch nicht gegangen ist), so kann dank horizontaler Skalierung selbst die kleinste general-purpose Instanz (m5.large) schon mal zu überdimensioniert sein, um einen Service zu hosten. Einige Microservices sind überhaupt nur an einem kleinen Teil der Anfragen beteiligt und verursachen dadurch über den Tag verteilt kaum zweistellige CPU-Auslastung. Gleichzeitig sollen sie aber über genug Headroom verfügen, um mit der Lastspitze umzugehen, wenn beispielsweise mal eben 1000 neue Produkte dem Shop hinzugefügt werden. Ähnlich verhält es sich bei Dev- und Staging-Umgebungen, die die meiste Zeit des Tages brach liegen, aber dennoch in der Lage sein sollen, kurzzeitig Production-ähnliche Last zu verarbeiten.

T-Instanzen setzen an dieser Problematik an und bieten die Möglichkeit, mit Lastspitzen umzugehen, ohne durchgängig eine überdimensionierte Instanz zu bezahlen. Jeder Instanztyp verfügt über eine sogenannte baseline performance in Prozent. Bleibt die Instanz unter diesem Wert, spart sie bis zu einem definierten Maximalwert Credits an. Steigt die Auslastung bei Lastspitzen über die Baseline, so werden die Credits wieder verbraucht. Für einen Credit kann eine vCPU eine Minute lang unter Volllast laufen. Hat eine T2-Instanz alle Credits verbraucht, so kann sie mit Standardeinstellungen nur noch die baseline performance erbringen. Alternativ können durch unlimited bursting ² zusätzliche vCPU Stunden pauschal mit je $0.05 abgegolten werden.

Neuerungen bei T3

Skylake Architecture

Das ist die wohl wichtigste Änderung für uns, und das nicht nur wegen der neuen AVX-512 Instructions. Denn als AWS im Januar 2018 ein neues AMI mit Sicherheitspatches für Meltdown/Spectre ausrollte, war das zugehörige Microcode-Update für Sandy Bridge Prozessoren noch nicht mal in Sicht. Als Folge verdoppelte sich mit dem neuen AMI auf den meisten unserer T2-Instanzen die CPU-Last. Dagegen war auf C5- und M5-Instanzen quasi keine Veränderung in der CPU-Last festzustellen, da Intel verständlicherweise den Fokus zuerst auf die aktuelle Skylake-Architektur legte.

Unlimited bursting by default

Da unlimited bursting standardmäßig aktiviert ist, fallen T3-Instanzen standardmäßig nicht mehr auf die baseline performance zurück, wenn alle Credits verbraucht sind. Das klingt jetzt erst mal nach Kostenfalle, tatsächlich ist aber eine t3.medium selbst bei 50% Auslastung mit etwa $0.07 pro Stunde noch günstiger als eine ähnlich ausgestattete c5.large ($0.085). Bei 100% Auslastung würden eine t3.medium mit etwa $0.12 pro Stunde zu Buche schlagen … und man sollte sich als Entwickler langsam mal Gedanken über horizontale Skalierung machen. 🙂

Nitro System

Unter dem Namen Nitro System fasst AWS Performance-Verbesserungen in mehreren Bereichen zusammen. Der neue Hypervisor soll im Vergleich zu “bare-metal” lediglich 1% Overhead produzieren ³, was ein sehr beeindruckender Wert ist! Außerdem verfügen nun auch die Netzwerkanbindung und EBS-Anbindung über eine Burst-Funktion mit Geschwindigkeiten im mittleren Gigabit-Bereich. Dagegen gibt AWS selbst die Netzwerkgeschwindigkeit bei T2-Instanzen mit “low to moderate” an, was sich bei hohen RPM-Werten auch durchaus in den Antwortzeiten bemerkbar macht.

The usual

Ebenso wie bereits T2 und quasi alle neueren Instanztypen, können auch T3-Instanzen nur in EC2-VPC und nicht in EC2-Classic gestartet werden ⁴ und nur AMIs mit hardware-beschleunigter Virtualisierung (HVM) sind kompatibel. ⁵

Wie sich die neuen T3 Instanzen in Production schlagen, wird mein Team leider erst herausfinden können, wenn der Instanztyp auch für Elastic Beanstalk ausgerollt wird, da die oben beschriebene Microservice Architektur auf diesem Service aufbaut. Aus Erfahrung muss man darauf nach der Ankündigung noch ungefähr einen Monat warten, aber im Forum wurde immerhin schon mal von offizieller Stelle bestätigt, dass die neuen AMIs in Arbeit sind. ⁶ Wir sind gespannt.

T-Instanzen sind nur eine Maßnahme, die man umsetzen kann, um die AWS-Rechnung zu reduzieren: cosee.biz/aws.