Wählen Sie den richtigen Instance-Typ für Windows-Workloads - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Wählen Sie den richtigen Instance-Typ für Windows-Workloads

Übersicht

Ein wesentlicher Unterschied zwischen Workloads, die in der Cloud betrieben werden, und lokalen Umgebungen ist die Praxis der Over-Provisioning. Wenn Sie physische Hardware für den Einsatz vor Ort kaufen, tätigen Sie Investitionen, die voraussichtlich für einen vorher festgelegten Zeitraum, in der Regel 3—5 Jahre, reichen werden. Um dem erwarteten Wachstum während der Lebensdauer der Hardware Rechnung zu tragen, wird die Hardware mit mehr Ressourcen erworben, als Ihre Arbeitslast derzeit benötigt. Aus diesem Grund ist die physische Hardware häufig überdimensioniert, was weit über den tatsächlichen Workload hinausgeht.

Die Technologie virtueller Maschinen (VM) hat sich als wirksames Mittel zur Nutzung überschüssiger Hardwareressourcen herausgestellt. Administratoren haben VMs mit vCPUs und RAM zu viel bereitgestellt, sodass der Hypervisor die physische Ressourcennutzung zwischen ausgelasteten und inaktiven Servern verwalten kann, indem er jeder VM ungenutzte Ressourcen zuweist. Bei der Verwaltung von VMs fungierten die jeder VM zugewiesenen vCPU- und RAM-Ressourcen eher als Ressourcenregler als als Indikatoren für die tatsächliche Nutzung. Eine Überzuweisung von VM-Ressourcen könnte leicht das Dreifache der verfügbaren Rechenressourcen übersteigen.

Amazon Elastic Compute Cloud (Amazon EC2) verzichtet auf eine übermäßige Bereitstellung von VMs auf der zugrunde liegenden Hardware, da dies unnötig ist. Cloud-Computing ist eine Betriebsausgabe, keine Kapitalausgabe, und Sie zahlen nur für das, was Sie tatsächlich nutzen. Wenn Ihr Workload in future mehr Ressourcen benötigt, stellen Sie diese dann bereit, wenn Sie sie tatsächlich benötigen, anstatt dies präventiv zu tun.

Es gibt Hunderte von Optionen für die Auswahl der richtigen Amazon EC2 EC2-Instance-Typen. Wenn Sie planen, einen Windows-Workload in die Cloud zu migrieren, AWS bietet er einen AWS OLA an, der Ihnen hilft, Ihren aktuellen Workload besser zu verstehen, und bietet ein Beispiel für dessen Leistung auf AWS. Die AWS OLA-Analyse zielt darauf ab, den geeigneten EC2-Instance-Typ und die passende Größe an Ihre tatsächliche Nutzung vor Ort anzupassen.

Wenn Sie bereits Workloads auf Amazon EC2 ausführen und nach Strategien zur Kostenoptimierung suchen, hilft Ihnen dieser Abschnitt des Handbuchs dabei, Unterschiede zwischen Amazon EC2 EC2-Instances und deren Anwendbarkeit auf typische Windows-Workloads zu identifizieren.

Empfehlungen zur Kostenoptimierung

Um die Kosten Ihrer EC2-Instance-Typen zu optimieren, empfehlen wir Ihnen, wie folgt vorzugehen:

  • Wählen Sie die richtige Instance-Familie für Ihren Workload

  • Machen Sie sich mit Preisunterschieden zwischen Prozessorarchitekturen vertraut

  • Machen Sie sich mit den Preis-/Leistungsunterschieden zwischen den EC2-Generationen vertraut

  • Migrieren Sie zu neueren Instances

  • Verwenden Sie Burstable-Instanzen

Wählen Sie die richtige Instance-Familie für Ihren Workload

Es ist wichtig, die richtige Instance-Familie für Ihren Workload auszuwählen.

Amazon EC2 EC2-Instances sind in die folgenden Gruppen unterteilt:

  • Allgemeine Zwecke

  • Für Datenverarbeitung optimiert

  • RAM-optimiert

  • Beschleunigtes Computing

  • Speicheroptimiert

  • HPC-optimiert

Die meisten Windows-Workloads lassen sich in die folgenden Kategorien einteilen:

  • Allgemeine Zwecke

  • Für Datenverarbeitung optimiert

  • RAM-optimiert

Um dies noch weiter zu vereinfachen, sollten Sie in jeder Kategorie eine EC2-Basisinstanz in Betracht ziehen:

  • Für die Datenverarbeitung optimiert — C6i

  • Allzweck — M6i

  • Speicheroptimiert — R6i

Die vorherige Generation von EC2-Instances wies geringfügige Unterschiede bei den Prozessortypen auf. Rechenoptimierte C5-Instances verfügen beispielsweise über schnellere Prozessoren als M5-Allzweck-Instances oder R5-Instances mit Speicheroptimierung. Die neueste Generation von EC2-Instances (C6i, M6i, R6i, C6a, M6a und R6a) verwenden in allen Instance-Familien denselben Prozessor. Da der Prozessor bei den Instances der neuesten Generation konsistent ist, hängt der Preisunterschied zwischen den Instance-Familien jetzt stärker von der RAM-Größe ab. Je mehr RAM eine Instance hat, desto teurer ist sie.

Das folgende Beispiel zeigt die Stundenpreise für eine Intel-basierte 4-vCPU-Instanz, die in der us-east-1 Region ausgeführt wird.

Instance vCPUs RAM Stundenpreis
c6i.xlarge 4 8 0,17$
m6i.xlarge 4 16 0,19$
r6i.xlarge 4 32 0,25$
Anmerkung

Die Preisgestaltung basiert auf Stundenpreisen auf Abruf in der us-east-1 Region.

Burstable-Instanzen

Es ist zwar eine bewährte Methode beim Cloud-Computing, ungenutzte Rechenressourcen auszuschalten, um Gebühren zu vermeiden, aber nicht alle Workloads können bei jedem Bedarf aus- und wieder eingeschaltet werden. Einige Workloads bleiben für längere Zeit ungenutzt, müssen aber rund um die Uhr verfügbar sein.

Burstable-Instances (T3) bieten die Möglichkeit, Workloads mit hoher Auslastung oder hoher Auslastung den ganzen Tag online zu halten und gleichzeitig die Rechenkosten niedrig zu halten. Burstable EC2-Instances verfügen über eine maximale Menge an vCPU-Ressourcen, die die Instance für kurze Zeit verwenden kann. Diese Instances verwenden ein System, das auf Burstable-CPU-Credits basiert. Diese Credits werden während der Leerlaufzeiten im Laufe des Tages gesammelt. Burstable-Instances bieten unterschiedliche vCPU-zu-RAM-Verhältnisse, was sie in einigen Fällen zu Alternativen zu berechnungsoptimierten Instances und in anderen zu anderen Allzweckinstanzen macht.

Das folgende Beispiel veranschaulicht die Stundenpreise für eine T3-Instance (d. h. eine Burstable-Instance), die in der Region ausgeführt wird. us-east-1

Instance vCPUs RAM (GB) Stundenpreis
t3.nano 2 0.5 0,0052$
t3.micro 2 1 0,0104$
t3.small 2 2 0,0208$
t3.medium 2 4 0,0416$
t3.large 2 8 0,0832$
t3.xlarge 4 16 0,1664$
t3.2xlarge 8 32 0,3328$
Anmerkung

Die Preisgestaltung basiert auf Stundenpreisen auf Abruf in der us-east-1 Region.

Machen Sie sich mit Preisunterschieden zwischen Prozessorarchitekturen vertraut

Intel-Prozessoren waren von Anfang an der Standard für EC2-Instances. Frühere Generationen von EC2-Instances, wie C5, M5 und R5, geben Intel nicht als Prozessorarchitektur an (da dies die Standardarchitektur war). Neuere Generationen von EC2-Instances, wie C6i, M6i und R6i, enthalten ein „i“, das die Verwendung eines Intel-Prozessors kennzeichnet.

Die Änderung der Anmerkungen zur Prozessorarchitektur ist auf die Einführung zusätzlicher Prozessoroptionen zurückzuführen. Der Prozessor, der am ehesten mit Intel vergleichbar ist, ist AMD (mit einem „a“ gekennzeichnet). AMD EPYC-Prozessoren verwenden dieselbe x86-Architektur und bieten eine ähnliche Leistung wie Intel-Prozessoren, jedoch zu einem niedrigeren Preis. Wie in den folgenden Preisbeispielen gezeigt, bieten AMD EC2-Instances im Vergleich zu ihren Intel-Pendants einen discount von etwa 10 Prozent auf die Rechenkosten.

Intel-Instanz Stundenpreis AMD-Instanz Preis Unterschied in%
c6i.xlarge 0,17$ c6a.xlarge 0,153$ 10 %
m6i.xlarge 0,192$ m6a.xlarge 0,1728$ 10 %
r6i.xlarge 0,252$ r6a.xlarge 0,2268$ 10 %
Anmerkung

Die Preisgestaltung basiert auf Stundenpreisen auf Abruf in der us-east-1 Region.

Die dritte wichtige Option für die Prozessorarchitektur sind AWS Graviton-Prozessoren (mit einem „g“ gekennzeichnet) auf EC2-Instances. Graviton-Prozessoren wurden von AWS entwickelt und bieten das beste Preis-Leistungs-Verhältnis auf Amazon EC2. Aktuelle Graviton-Prozessoren sind nicht nur 20 Prozent günstiger als ihre Gegenstücke von Intel, sondern bieten auch eine Leistungssteigerung von 20 Prozent oder mehr. Es wird erwartet, dass die nächste Generation von Graviton-Prozessoren diesen Leistungsunterschied weiter ausbauen wird. Tests ergaben eine zusätzliche Leistungssteigerung von 25 Prozent.

Windows Server kann nicht auf Graviton-Prozessoren ausgeführt werden, die auf der ARM-Architektur basieren. Tatsächlich funktioniert Windows Server nur auf x86-Prozessoren. Mit Graviton-basierten Instances für Windows Server können Sie das Preis-Leistungs-Verhältnis zwar nicht um 40 Prozent steigern, aber Sie können Graviton-Prozessoren dennoch mit bestimmten Microsoft-Workloads verwenden. Neuere Versionen von.NET können beispielsweise unter Linux ausgeführt werden. Das bedeutet, dass diese Workloads ARM-Prozessoren verwenden und von schnelleren, kostengünstigeren Graviton EC2-Instances profitieren können.

Das folgende Beispiel veranschaulicht die Stundenpreise für eine Graviton-Instance, die in der Region ausgeführt wird. us-east-1

Intel-Instanz Stundenpreis Graviton-Instanz Stundenpreis Unterschied in%
c6i.xlarge 0,17$ c6g.xlarge 0,136$ 20 %
m6i.xlarge 0,192$ m6g.xlarge 0,154$ 20 %
r6i.xlarge 0,252$ r6g.xlarge 0,2016$ 20 %
Anmerkung

Die Preisgestaltung basiert auf Stundenpreisen auf Abruf in der us-east-1 Region.

In der folgenden Tabelle werden die Preise von Instances der M-Serie verglichen.

Preisvergleich der M-Serie

Machen Sie sich mit den Preis-/Leistungsunterschieden zwischen den EC2-Generationen vertraut

Eines der beständigsten Merkmale von Amazon EC2 ist, dass jede neue Generation ein besseres Preis-Leistungs-Verhältnis bietet als ihre Vorgängerin. Wie die folgende Tabelle zeigt, sinkt der Preis für EC2-Instances der neueren Generation mit jeder nachfolgenden Version.

Für Berechnungen optimierte Instance Stundenpreis Allzweckinstanz Stundenpreis Speicheroptimierte Instanz Stundenpreis
C1.xlarge 0,52$ M1.x groß 0,35$ r1.x groß
C3.x groß 0,21$ M3.x groß 0,266$ r3.xlarge 0,333$
C5.x groß 0,17$ M5.x groß 0,192$ r5.xlarge 0,252$
Anmerkung

Die Preisgestaltung basiert auf Stundenpreisen auf Abruf in der us-east-1 Region.

In der folgenden Tabelle werden die Kosten der verschiedenen Generationen von Instances der C-Serie verglichen.

Preisvergleich der C-Serie

Instances der 6. Generation haben jedoch denselben Preis wie die 5. Generation, wie die folgende Tabelle zeigt.

Für Berechnungen optimierte Instanz Stundenpreis Allzweckinstanz Stundenpreis Speicheroptimierte Instanz Stundenpreis
C5.xlarge 0,17$ M5.x groß 0,192$ r5.xlarge 0,252$
C6i.X groß 0,17$ M6i. XL groß 0,192$ r6i.xlarge 0,252$
Anmerkung

Die Preisgestaltung basiert auf Stundenpreisen auf Abruf in der us-east-1 Region.

Trotz der gleichen Kosten bietet die neuere Generation aufgrund schnellerer Prozessoren, verbessertem Netzwerkdurchsatz und erhöhtem Amazon Elastic Block Store (Amazon EBS) -Durchsatz und IOPS ein hervorragendes Preis-Leistungs-Verhältnis.

Eine der wichtigsten Verbesserungen des Preis-Leistungs-Verhältnisses ist die Erweiterung der X2i-Instance. Diese Generation der Instance bietet ein bis zu 55 Prozent besseres Preis-Leistungs-Verhältnis als die vorherige Generation. Wie die folgende Tabelle zeigt, weist der x2iedn Verbesserungen in allen Leistungsaspekten auf (und das alles zum gleichen Preis wie die vorherige Generation).

Instance Stundenpreis vCPUs RAM Geschwindigkeit des Prozessors Instance-Speicher Netzwerk Amazon EBS-Durchsatz EBS-IOPS
x1e.2xlarge 1,66$ 8 244 2,3 GHz 237 GB SSD 10 Gbit/s 125 MB/s 7400
x1 i d n.2 x groß 1,66$ 8 256 3,5 GHz 240 GB NVMe SSD 25 Gbit/s 2500 MB/s 65000
Anmerkung

Die Preisgestaltung basiert auf Stundenpreisen auf Abruf in der us-east-1 Region.

Beispielszenarien

Stellen Sie sich das Beispiel eines Analyseunternehmens vor, das Lieferfahrzeuge verfolgt und die Leistung seines SQL Servers verbessern möchte. Nachdem ein MACO-SME die Leistungsengpässe dieses Unternehmens überprüft hat, wechselt das Unternehmen von x1e.2xlarge-Instances zu x2iedn.xlarge-Instances. Die neue Instanzgröße ist kleiner, aber die Verbesserungen der x2-Instanzen ermöglichen eine höhere Leistung und Optimierung von SQL Server durch den Einsatz von Buffer Pool Extensions. Dadurch kann das Unternehmen ein Downgrade von der SQL Server Enterprise Edition auf die SQL Server Standard Edition durchführen. Es ermöglicht dem Unternehmen auch, seine SQL Server-Lizenzierung von 8 vCPUs auf 4 vCPUs zu reduzieren.

Vor der Optimierung:

Server EC2-Instance SQL Server Edition Monatliche Kosten
prodDB1 x1e.2xlarge Enterprise 3.918,64$
Produkt DB2 x1e.2xlarge Enterprise 3.918,64$
Gesamt     7.837,28$

Nach der Optimierung:

Server EC2-Instance SQL Server Edition Monatliche Kosten
prodDB1 x2iedn.xlarge Standard 1.215,00$
Produkt DB2 x2iedn.xlarge Standard 1.215,00$
Gesamt     2.430,00$

Alles in allem ermöglicht der Wechsel von x1e.2xlarge-Instances zu x2iedn.xlarge-Instances dem Unternehmen im Beispielszenario, 5.407$ pro Monat auf seinen Produktionsdatenbankservern einzusparen. Dadurch werden die Gesamtkosten des Workloads um 69 Prozent reduziert.

Anmerkung

Die Preisgestaltung basiert auf den Stundenpreisen auf Abruf in der us-east-1 Region.

Migrieren Sie zu neueren Instanzen

Ältere Generationen von Amazon EC2 laufen auf dem Xen-Hypervisor, während neuere Generationen auf dem AWS Nitro-System laufen. Das Nitro-System stellt Ihren Instances fast alle Rechen- und Speicherressourcen der Host-Hardware zur Verfügung. Dies führt zu einer verbesserten Gesamtleistung. Bei der Migration von Xen- zu Nitro-basierten Instances sind besondere Überlegungen zu beachten. AWS Windows-AMIs werden beispielsweise mit Standardeinstellungen und Anpassungen konfiguriert, die von den Microsoft-Installationsmedien verwendet werden. Die Anpassungen umfassen Treiber und Konfigurationen, die die Instance-Typen der neuesten Generation unterstützen (Instances, die auf dem Nitro System basieren).

Wenn Sie Instances über benutzerdefinierte Windows-AMIs oder über von Amazon bereitgestellte Windows-AMIs starten, die vor August 2018 erstellt wurden, empfehlen wir Ihnen, die Schritte unter Migrieren zu Instance-Typen der neuesten Generation in der Amazon EC2 EC2-Dokumentation durchzuführen.

Verwenden Sie Burstable-Instances

Burstable-Instances sind zwar eine gute Möglichkeit, Rechenkosten zu sparen, wir empfehlen jedoch, sie in den folgenden Szenarien zu vermeiden:

  • Die Mindestspezifikationen für Windows Server mit Desktop Experience erfordern 2 GB RAM. Vermeiden Sie die Verwendung von t3.micro- oder t3.nano-Instances mit Windows Server, da ihnen die Mindestmenge an RAM fehlt.

  • Wenn Ihre Arbeitslast stark ist, aber nicht lange genug ungenutzt bleibt, um Burst-Credits aufzubauen, ist die Verwendung normaler EC2-Instances effizienter als die Verwendung von Burstable-Instances. Wir empfehlen, Ihre CPU-Guthaben zu überwachen, um dies zu überprüfen.

  • Wir empfehlen, in den meisten Szenarien die Verwendung von Burstable-Instanzen mit SQL Server zu vermeiden. Die Lizenzierung für SQL Server basiert auf der Anzahl der vCPUs, die einer Instanz zugewiesen sind. Wenn SQL Server die meiste Zeit des Tages inaktiv ist, würden Sie für SQL-Lizenzen zahlen, die Sie nicht vollständig nutzen. In diesen Szenarien empfehlen wir, mehrere SQL Server-Instanzen auf einem größeren Server zu konsolidieren.

Nächste Schritte

Wir empfehlen Ihnen, die folgenden nächsten Schritte zu unternehmen, um Ihre Kosten für Amazon EC2 EC2-Windows-Instances zu optimieren:

  • Verwenden Sie die EC2-Instance der neuesten Generation, um das beste Preis-Leistungs-Verhältnis zu erzielen.

  • Verwenden Sie EC2-Instances mit AMD-Prozessoren, um die Rechenkosten um zehn Prozent zu senken.

  • Maximieren Sie die Ressourcennutzung, indem Sie einen EC2-Instance-Typ wählen, der zu Ihrer Arbeitslast passt.

Die folgende Tabelle zeigt Beispiele für typische Startpunkte für Windows-Workloads. Zusätzliche Optionen sind verfügbar, z. B. Instanzspeichervolumes zur Verbesserung von SQL Server-Workloads oder EC2-Instances mit einem viel größeren Verhältnis von vCPU zu RAM. Wir empfehlen Ihnen, Ihre Workloads gründlich zu testen und Überwachungstools zu verwenden, um die erforderlichen Anpassungen vorzunehmen. AWS Compute Optimizer

Workload Typisch Optional
Active Directory T3, M6i R6i
Dateiserver T3, M6i C6i
Web-Server T3, C6i M6i, R6i
SQL Server R6i x2iedn, x2IEZn

Wenn Sie Ihren EC2-Instance-Typ ändern müssen, umfasst der Vorgang in der Regel nur einen einfachen Serverneustart. Weitere Informationen finden Sie unter Ändern des Instance-Typs in der Amazon EC2 EC2-Dokumentation.

Bevor Sie Ihren Instance-Typ ändern, empfehlen wir Ihnen, Folgendes zu beachten:

  • Sie müssen Ihre von Amazon EBS unterstützten Instances beenden, bevor Sie den Instance-Typ ändern können. Achten Sie darauf, Ausfallzeiten einzuplanen, während Ihre Instance gestoppt ist. Das Anhalten der Instance und die Änderung des Instance-Typs können ein paar Minuten dauern. Der Neustart Ihrer Instance kann je nach den Startup-Skripten Ihrer Anwendung unterschiedlich lange dauern. Weitere Informationen finden Sie unter Beenden und Starten Ihrer Instance in der Amazon EC2 EC2-Dokumentation.

  • Wenn Sie eine Instance beenden und starten, AWS wird die Instance auf neue Hardware verschoben. Wenn Ihre Instance über eine öffentliche IPv4-Adresse verfügt, gibt die Adresse AWS frei und gibt Ihrer Instance eine neue öffentliche IPv4-Adresse. Wenn Sie eine öffentliche IPv4-Adresse benötigen, die sich nicht ändert, verwenden Sie eine Elastic IP-Adresse.

  • Sie können den Instance-Typ nicht ändern, wenn der Ruhezustand auf der Instance aktiviert ist.

  • Sie können den Instance-Typ einer Spot-Instance nicht ändern.

  • Wenn sich Ihre Instance in einer Auto Scaling-Gruppe befindet, markiert Amazon EC2 Auto Scaling die gestoppte Instance als fehlerhaft und kann sie beenden und eine Ersatz-Instance starten. Um dies zu verhindern, können Sie die Skalierungsprozesse für die Gruppe anhalten, während Sie den Instance-Typ ändern. Weitere Informationen finden Sie unter Einen Prozess für eine Auto Scaling Scaling-Gruppe aussetzen und fortsetzen in der Amazon EC2 Auto Scaling Scaling-Dokumentation.

  • Wenn Sie den Instance-Typ einer Instance mit NVMe-Instance-Speicher-Volumes ändern, verfügt die aktualisierte Instance möglicherweise über zusätzliche Instance-Speicher-Volumes, da alle NVMe-Instance-Speicher-Volumes verfügbar sind, auch wenn sie nicht im Amazon Machine Image (AMI) oder der Instance-Block-Gerätezuordnung angegeben sind. Anderenfalls weist die aktualisierte Instance die gleiche Anzahl von Instance-Speicher-Volumes auf, die Sie beim Starten der ursprünglichen Instance angegeben haben.

Weitere Ressourcen