Nutzung des AWS Compute Optimizer für kontinuierliches Right-Sizing und Kostensenkung

AWS Right-Sizing klingt nach einer Finanzübung, bis die erste schlechte Änderung eine Produktionsworkload lahmlegt. Die nützliche Version ist vorsichtiger: Finden Sie Ressourcen, die eindeutig zu groß, eindeutig zu klein sind oder auf einer ungünstigen Infrastrukturgeneration laufen, und nehmen Sie dann Änderungen vor, die Verkehrsmuster, Zustand, Rollback und Anwendungsverhalten respektieren.

AWS Compute Optimizer unterstützt diese Arbeit, indem es Ressourcenkonfiguration und Nutzungsmetriken analysiert und dann Empfehlungen für Dienste wie EC2-Instanzen, Auto Scaling-Gruppen, EBS-Volumes, ECS-Dienste auf Fargate und Lambda-Funktionen erstellt. Die Empfehlungen sind nützlich, sollten aber als Entscheidungshilfe und nicht als automatische Wahrheit betrachtet werden. Compute Optimizer kann Metriken sehen. Es kann nicht immer Release-Kalender, Kundenverpflichtungen, Lizenzbesonderheiten oder den seltsamen Batch-Job sehen, der nur am Monatsende läuft.

AWS Compute Optimizer verstehen

AWS Compute Optimizer liefert Empfehlungen durch die Analyse historischer Nutzungsmetriken für unterstützte Ressourcen. Der standardmäßige Rückblick basiert üblicherweise auf der letzten Vergangenheit, und erweiterte Infrastrukturmetriken können den Analysezeitraum für einige Ressourcentypen verlängern. Die genaue Verfügbarkeit und Aufbewahrungsdauer kann je nach Ressourcentyp, Region, Kontoeinstellungen und AWS-Funktionsänderungen variieren. Überprüfen Sie daher die aktuelle Dienstseite, bevor Sie einen starren Prozess um eine Zahl herum aufbauen.

ACO bewertet mehrere Faktoren, darunter CPU-Auslastung, Speichernutzung (falls der entsprechende CloudWatch-Agent installiert ist), Netzwerkdurchsatz und Datenträger-I/O, und generiert Empfehlungen, die sowohl Kosteneffizienz als auch Leistung priorisieren.

Wichtige von ACO bereitgestellte Metriken

Optimierungsergebnisse: Kategorisierung der Ressource (z. B. Überdimensioniert, Unterdimensioniert, Optimiert).
Geschätzte monatliche Einsparungen: Prognostizierte Kostenreduzierung bei Umsetzung der Empfehlung.
Leistungsrisiko: Eine niedrige, mittlere oder hohe Bewertung, die die Wahrscheinlichkeit angibt, dass die Umsetzung der Empfehlung die Leistung der Workload negativ beeinflusst.
Empfohlene Optionen: Spezifische alternative Ressourcenkonfigurationen (z. B. Instanztypen, Speichereinstellungen, EBS-Volume-Spezifikationen).

Hinweis: Compute Optimizer-Empfehlungen selbst sind in vielen häufigen Anwendungsfällen ohne separate Servicegebühr verfügbar, aber optionale erweiterte Metriken und die analysierten Ressourcen können sich dennoch auf Ihre Rechnung auswirken. Überprüfen Sie die Preise in Ihrem Konto, bevor Sie optionale Funktionen umfassend aktivieren.

Right-Sizing von Amazon EC2-Instanzen

EC2-Instanzen sind oft der größte einzelne Treiber der Cloud-Computing-Kosten. ACO bietet maßgeschneiderte Empfehlungen für eigenständige Instanzen und Instanzen in Auto Scaling-Gruppen (ASGs).

Identifizierung über- und unterdimensionierter Instanzen

ACO kategorisiert EC2-Instanzen basierend auf seiner Analyse:

Überdimensioniert: Instanzen, die eine durchweg niedrige Auslastung für die Metriken aufweisen, die Compute Optimizer sehen kann. Es kann vorschlagen, auf einen kleineren oder anderen Instanztyp zu wechseln.
Unterdimensioniert: Instanzen, die eine hohe Auslastung oder Ressourcendruck aufweisen. Es kann eine größere Instanz, eine andere Familie oder eine Konfiguration mit besseren CPU-, Speicher-, Netzwerk- oder Speichereigenschaften vorschlagen.

Implementierung von EC2-Right-Sizing-Empfehlungen

Die Implementierung einer Änderung erfordert sorgfältige Planung, insbesondere für Produktionsworkloads. Der Prozess zum Ändern eines Instanztyps umfasst typischerweise das Stoppen, Modifizieren und Neustarten der Instanz.

Beispiel: Modifizieren einer überdimensionierten Instanz über die CLI

Wenn Compute Optimizer empfiehlt, eine Instanz von m5.large auf t3.large zu ändern, sind die mechanischen Schritte für eine EBS-gestützte Instanz:

Stoppen Sie die Instanz:

aws ec2 stop-instances --instance-ids i-1234567890abcdef0

Ändern Sie den Instanztyp:

aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --instance-type "{'Value': 't3.large'}"

Starten Sie die Instanz:

aws ec2 start-instances --instance-ids i-1234567890abcdef0

Best Practice: Führen Sie diese Änderungen immer in verkehrsarmen Zeiten durch und überwachen Sie die Instanzmetriken (CPU, Latenz, Anwendungslogs) für 24-48 Stunden nach der Implementierung, um sicherzustellen, dass die neue Größe Spitzenlast ohne Leistungseinbußen bewältigen kann.

Überprüfen Sie vor dem Ändern des Typs, ob die Instanz Teil einer Auto Scaling-Gruppe ist, Instance Store-Volumes verwendet, Anforderungen an Placement Groups hat, ENA- oder NVMe-Namenskonventionen verwendet oder an ein Lizenzmodell gebunden ist. Bei Produktionsdiensten ist es oft sicherer, die neue Größe in eine Launch-Vorlage einzubacken, Instanzen schrittweise zu ersetzen und Load Balancer die Verbindungen abfließen zu lassen.

Optimierung von Amazon EBS-Volumes

Compute Optimizer erweitert seine Empfehlungen auf Elastic Block Store (EBS)-Volumes, die an EC2-Instanzen angeschlossen sind. Die Optimierung konzentriert sich hier auf die Maximierung der Leistung pro Dollar durch die Empfehlung moderner Volume-Typen und die Anpassung von IOPS/Durchsatz-Einstellungen.

Migrationsempfehlungen

Eine häufige Optimierung ist die Migration älterer Allzweck-Volumes, insbesondere gp2, zu gp3, wo es zur Workload passt.

Volume-Typ	Vorteil
`gp2`	Die Leistung skaliert mit der Volume-Größe und Burst-Guthaben.
`gp3`	Die Leistung kann innerhalb der Servicegrenzen getrennt von der Größe konfiguriert werden.

Compute Optimizer kann basierend auf beobachteten Nutzungsmustern spezifische IOPS- und Durchsatzwerte empfehlen. Behandeln Sie diese Empfehlungen als Ausgangspunkt. Ein Datenbank-Volume mit geringem aktuellen Schreibvolumen benötigt möglicherweise dennoch Spielraum für Wartungsfenster, Kompaktierung, Indexerstellung, Backups oder Failover-Nachholung.

Umsetzbarer Schritt: Modifizieren eines Volumes

EBS-Volume-Änderungen können normalerweise durchgeführt werden, während das Volume verwendet wird (im Gegensatz zum Ändern eines EC2-Instanztyps), obwohl die Leistungsauswirkungen berücksichtigt werden sollten.

# Beispiel: Migration eines Volumes zu gp3 und Festlegen spezifischer IOPS/Durchsatz
aws ec2 modify-volume \
    --volume-id vol-fedcba9876543210 \
    --volume-type gp3 \
    --iops 3000 \
    --throughput 125

Überwachen Sie den Modifikationsstatus nach dem Befehl:

aws ec2 describe-volumes-modifications \
  --volume-ids vol-fedcba9876543210

Testen Sie die Änderung bei kritischen Datenbanken zuerst an einem Replikat oder einer Staging-Kopie. Eine Volume-Typ-Änderung kann online sein, aber die Workload kann dennoch I/O-Verhaltensänderungen spüren, wenn die neuen IOPS- oder Durchsatz-Einstellungen zu niedrig sind.

Right-Sizing von AWS Lambda-Funktionen

Für serverlose Workloads liefert Compute Optimizer kritische Einblicke in AWS Lambda-Funktionen. Bei Lambda bestimmt die Speichereinstellung die Menge an vCPU, die der Funktion zugewiesen wird. Right-Sizing von Lambda bedeutet in erster Linie, die niedrigste Speicherkonfiguration zu finden, die dennoch die Leistungsziele erfüllt.

Der Speicher/CPU-Kompromiss

Compute Optimizer analysiert Lambda-Nutzungs- und Dauer-Muster, um Speichereinstellungen zu empfehlen. Einer Funktion könnten 1024 MB zugewiesen sein, aber sie könnte bei 512 MB akzeptabel funktionieren. Eine andere Funktion könnte günstiger werden, wenn der Speicher erhöht wird, weil die zusätzliche CPU die Dauer ausreichend reduziert, um die größere Speicherzuweisung auszugleichen.

Dieser zweite Fall überrascht Leute. Die Lambda-Kosten hängen vom zugewiesenen Speicher und der Dauer ab, daher ist die günstigste Einstellung nicht immer der kleinste Speicherwert. Testen Sie repräsentative Ereignisse, bevor Sie Empfehlungen breit anwenden.

Implementierung der Lambda-Funktionsoptimierung

Die Lambda-Optimierung ist unkompliziert und erfordert normalerweise ein einfaches Update der Funktionskonfiguration.

Beispiel: Aktualisieren der Lambda-Speicherkonfiguration

Wenn ACO empfiehlt, eine Funktion von 2048 MB auf 1024 MB umzustellen:

aws lambda update-function-configuration \
    --function-name MyOptimizedFunction \
    --memory-size 1024

Integration kontinuierlicher Optimierung in Ihren Workflow

Right-Sizing sollte keine einmalige Prüfung sein, sondern eine kontinuierliche Disziplin. Compute Optimizer erleichtert dies durch seine API und Integration mit AWS Organizations.

1. Zentralisierte Verwaltung

Wenn Sie AWS Organizations verwenden, bestimmen Sie einen delegierten Administrator für Compute Optimizer. Dies ermöglicht ACO, konsolidierte Empfehlungen über alle Konten hinweg bereitzustellen und bietet eine ganzheitliche Sicht auf potenzielle unternehmensweite Einsparungen.

2. Automatisierung und Benachrichtigung

Verwenden Sie die Compute Optimizer-API und integrieren Sie sie mit AWS CloudWatch Events oder Lambda, um automatisierte Workflows zu erstellen:

Geplante Berichterstattung: Richten Sie einen täglichen oder wöchentlichen Trigger ein, der die neuesten hochprioritären Empfehlungen abruft (z. B. solche mit den höchsten geschätzten Einsparungen).
Benachrichtigung: Lösen Sie Warnungen über SNS aus, wenn ACO Ressourcen mit bestimmten Ergebnissen identifiziert (z. B. unterdimensionierte Instanzen mit hohem Leistungsrisiko).
Semi-automatisierte Implementierung: Verwenden Sie für risikoarme, einsparungsreiche Empfehlungen (wie EBS-gp3-Migration) Lambda-Funktionen, um automatisch Änderungsanfragen zu generieren oder die Änderung direkt anzuwenden, nachdem eine erforderliche Governance-Schwelle überschritten wurde.

# Konzeptionelles Python-Snippet mit boto3 zum Abrufen von Empfehlungen
import boto3

aco_client = boto3.client('compute-optimizer')

response = aco_client.get_ec2_instance_recommendations(
    filters=[
        {'name': 'finding', 'values': ['Overprovisioned']}
    ]
)
# Verarbeiten und Handeln nach den empfohlenen Optionen...

Halten Sie die Implementierung von der Empfehlungssammlung getrennt. Ein wöchentlicher Bericht kann sicher Kandidaten auflisten. Ein Bot, der Instanzen stoppt oder Lambda-Speicher ohne Workload-Kontext ändert, kann Vorfälle verursachen. Ein guter Mittelweg ist, Tickets oder Pull-Requests mit der Empfehlung, aktuellen Metriken, vorgeschlagener Änderung, geschätzten Einsparungen und Rollback-Plan zu erstellen.

Wie man eine Empfehlung vor der Umsetzung prüft

Stellen Sie für jede Empfehlung ein paar praktische Fragen:

Wird die Ressource noch genutzt, oder ist Löschung eine bessere Antwort als Größenänderung?
Enthält der Rückblickzeitraum normalen Spitzenverkehr, Batch-Fenster und aktuelle Releases?
Sind Speicherdaten für EC2 verfügbar, oder basiert die Empfehlung hauptsächlich auf CPU und Netzwerk?
Ist die Instanz zustandsbehaftet, lizenziert, an Hardware gebunden oder manuell konfiguriert?
Kann die Änderung hinter einer Auto Scaling-Gruppe, einem Blue/Green-Deployment oder einem Replikat ausgerollt werden?
Welche Metrik würde beweisen, dass die Änderung funktioniert hat oder fehlgeschlagen ist?

Zum Beispiel kann eine EC2-Instanz, die einen nächtlichen Bericht ausführt, während der Geschäftszeiten untätig erscheinen und 40 Minuten nach Mitternacht extrem beschäftigt sein. Eine Empfehlung, die auf breiten Durchschnittswerten basiert, könnte eine Verkleinerung vorschlagen, aber die eigentliche Frage ist, ob der Bericht dennoch vor der Geschäftsfrist fertig wird. Kosteneinsparungen, die das Batch-Fenster brechen, sind keine Einsparungen.

Rollout-Muster, die das Risiko reduzieren

Der sicherste Implementierungspfad hängt von der Ressource ab.

Bei zustandslosen EC2-Diensten hinter einem Load Balancer bevorzugen Sie das Ersetzen von Instanzen durch eine Auto Scaling-Gruppe oder Bereitstellungspipeline, anstatt eine laufende Instanz von Hand zu stoppen. Aktualisieren Sie die Launch-Vorlage, fügen Sie eine Instanz mit dem neuen Typ hinzu, beobachten Sie Health Checks und Anwendungsmetriken und rollen Sie dann den Rest schrittweise aus. Dies gibt Ihnen ein natürliches Rollback: Setzen Sie die alte Launch-Vorlagenversion zurück und ersetzen Sie die neuen Instanzen.

Bei zustandsbehafteten EC2-Hosts gehen Sie einen langsameren Weg. Bestätigen Sie Backups, verstehen Sie angeschlossene Volumes, überprüfen Sie Wartungsfenster und stellen Sie sicher, dass die Anwendung einen Stop/Start-Zyklus tolerieren kann. Einige ältere Instanzfamilien und neuere Familien legen Datenträger oder Netzwerkgeräte unterschiedlich offen, sodass Startskripte, die einen Gerätenamen annehmen, nach einer Typänderung brechen können.

Bei EBS beobachten Sie sowohl Kosten- als auch Leistungsmetriken nach der Änderung des Volume-Typs oder der bereitgestellten Leistung. Eine niedrigere monatliche Schätzung ist nicht genug. Überprüfen Sie die Warteschlangenlänge, Latenz, Durchsatz und anwendungsspezifische Symptome. Wenn das Volume eine Datenbank unterstützt, sagt Ihnen die Anwendungslatenz möglicherweise mehr als die Volume-Grafik allein.

Bei Lambda veröffentlichen Sie eine neue Version oder einen aliasbasierten Rollout, wenn die Funktion wichtig ist. Senden Sie einen kleinen Teil des Datenverkehrs an die neue Speichereinstellung, vergleichen Sie Dauer, Fehler, Kaltstarts und nachgelagerten Druck und verschieben Sie dann mehr Datenverkehr. Eine Funktion, die mit mehr Speicher schneller wird, kann mehr Druck auf eine Datenbank oder API ausüben, die sie aufruft. Beobachten Sie daher den gesamten Pfad.

Empfehlungen klar melden

Ein nützlicher Right-Sizing-Bericht sollte keine Tabelle mit Instanz-IDs ohne Kontext sein. Fügen Sie die aktuelle Konfiguration, empfohlene Konfiguration, beobachtetes Nutzungsfenster, geschätzte monatliche Einsparungen, Leistungsrisiko, Eigentümer, vorgeschlagene Rollout-Methode und Rollback-Plan hinzu. Fügen Sie eine kurze Notiz hinzu, die erklärt, warum die Empfehlung akzeptiert, zurückgestellt oder abgelehnt wird.

Abgelehnte Empfehlungen sind dennoch nützlich. Ein Datenbankserver mag überdimensioniert erscheinen, weil er für Failover dimensioniert ist, nicht für durchschnittlichen Datenverkehr. Ein Lizenzserver benötigt möglicherweise eine feste Instanzfamilie. Ein Host mit geringer Nutzung wartet möglicherweise auf eine geplante Migration. Das Erfassen dieser Gründe verhindert, dass dieselbe Empfehlung jeden Monat erneut diskutiert wird.

Best Practices für die Nutzung von Compute Optimizer

Bereich	Best Practice
Überwachungszeitraum	Stellen Sie sicher, dass Ressourcen mindestens 14 Tage lang unter typischer Last gelaufen sind, bevor Sie Empfehlungen vertrauen.
Leistungstests	Führen Sie nach der Implementierung einer Verkleinerungsempfehlung immer Lasttests durch, um sicherzustellen, dass die Anwendung die erforderlichen SLOs (Service Level Objectives) einhält.
Spezialisierte Workloads	Seien Sie vorsichtig bei zustandsbehafteten Anwendungen, Datenbanken oder Lizenzservern von Drittanbietern, die bestimmte Instanztypen oder Mindestressourcen erfordern könnten, selbst wenn ACO eine kleinere Größe empfiehlt.
Speichermetrik	Installieren Sie für EC2 den CloudWatch-Agenten, um detaillierte Speichernutzungsdaten zu sammeln. Ohne dies stützen sich die Right-Sizing-Empfehlungen von ACO hauptsächlich auf CPU und Netzwerk, was unvollständig sein kann.
Kontinuierliche Überprüfung	Behandeln Sie das ACO-Dashboard als lebendiges Dokument. Workloads ändern sich ständig und erfordern eine regelmäßige Neubewertung der Ressourcengröße.

Abschließende Prüfung

AWS Compute Optimizer ist am wertvollsten, wenn es Teil einer Überprüfungsgewohnheit wird. Nutzen Sie es, um Verschwendung zu finden, unterdimensionierte Ressourcen zu entdecken und alte Annahmen in Frage zu stellen. Bringen Sie dann den Kontext ein, den AWS nicht ableiten kann: Release-Zeitplan, Spitzenereignisse, Kundenversprechen, Fehlerdomänen und Rollback-Pfade. Das beste Right-Sizing-Programm ist nicht das, das die meisten Empfehlungen akzeptiert. Es ist das, das Geld spart, ohne die Produktion fragiler zu machen.