Bemerkung
Dieser Artikel wird regelmäßig auf dem neuesten Stand gehalten. Aktueller Stand ist Februar 2025.

Vielleicht ist dein Unternehmen bereits bei AWS und die monatliche Rechnung bereitet dir Bauchschmerzen. Oder du willst von On-Premise in die Cloud wechseln, hast aber Angst vor Überraschungen.

Die Umstellung von On-Premise auf die Cloud kann eine Menge Geld und Kopfschmerzen sparen. Es werden weniger Mitarbeiter für die Infrastruktur benötigt, die Sicherheit wird (mehr oder weniger) vom Cloud-Anbieter gewährleistet und nicht von einem überlasteten Mitarbeiter, und man kann Dinge, die nicht mehr benötigt werden einfach abschalten.

Dennoch kann die Cloud schnell teuer werden, wenn man nicht aufpasst. Wenn jeder im Unternehmen die Schlüssel hat, um Server oder Datenbanken hochzufahren, kann man am Ende des Monats eine Überraschung erleben.

Aber selbst wenn alle Teams darauf achten, nur das zu verwenden, was gebraucht wird, gibt es einige versteckte Kostenfaktoren, an die man vielleicht nicht denkt. Hier sind zum Beispiel zwei:

  • S3-Speicher ist superbillig. Die Datenübertragung von S3 nicht so sehr.
  • EC2-Server haben einen klar definierten Preis pro Instanz, aber es gibt zusätzliche Kosten: Load balancing, elastische IPs, Datentransfer nach draußen, Blockspeicher, Monitoring.

Hier sammle ich einige Erkenntnisse, getrennt nach Diensten.

Allgemeine Überlegungen Link zu Überschrift

Abschalten, was nicht benötigt wird

  • Kann man Dev und Staging nachts und am Wochenende abschalten?
  • Ist es möglich Production nachts teilweise herunterfahren?
  • Daten entfernen oder archivieren. Glacier Deep Archive super günstig und trotzdem sind die Daten in ein paar Tagen verfügbar
  • Backups löschen, die nicht mehr benötigt werden
  • Gibt es Server, die noch laufen (vielleicht als Entwicklungsumgebung für jemanden, der das Unternehmen bereits verlassen hat) und nichts tun?
  • Infrastructure as Code verwenden. Das macht es einfach, Dinge abzuschalten und neu zu erstellen, wenn man sie tatsächlich brauchen.
  • Cloudbasierten KPI-Dashboards erstellen, um einen Überblick zu bekommen.

Taggen von Ressourcen

Tags helfen dabei einen Überblick über alle Ressource zu bekommen.

Es gibt zwei Arten von Tags: AWS-generierte und benutzerdefinierte Tags. Erstere werden automatisch generiert, z. B. wenn eine Ressource von CloudFormation generiert wurde, erhält sie ein entsprechendes aws:cloudformation:…-Tag. Sie sind jedoch für diese Aufgabe nicht geeignet, da sie sich von Dienst zu Dienst unterscheiden.

Benutzerdefinierte Tags werden vom Benutzer definiert, entweder während der Erstellung oder später. Über Service Control Policies können Sie neu erstellte Ressourcen dazu zwingen, ein bestimmtes Tag zu haben.

Welche Tags wollen wir nun? Das hängt vom Unternehmen ab. Beispiele sind: environment (Dev, Staging, Qa, Prod), owner (die E-Mail-Adresse des Erstellers oder ein Teamname), product oder service. (Daran denken, den Tag als cost allocation tag zu aktivieren)

Entwickler und PMs mit den Kosten vertraut machen.

  • Vielleicht wussten sie nicht, dass das Herumspielen mit dem neuesten KI-Spielzeug 5k pro Monat kostet.

  • Es gibt Dienste von Drittanbietern, die regelmäßig E-Mails mit einer Kostenaufstellung an interessierte Parteien senden können und vielleicht sogar deren Wettbewerbsgeist wecken, um die Zahlen zu ermitteln.

Mit AWS sprechen

  • Wenn Sie monatlich einen hohen sechsstelligen Betrag ausgeben, ist AWS möglicherweise bereit, die Preise zu senken, z. B. die egress networking Kosten, und zwar oft um einen erheblichen Betrag.
  • Frag deinen AWS Account Manager, ein Gespräch mit einem Experten für Kostenoptimierung in die Wege zu leiten, das kostet nichts.

Premium AWS-Support abschalten

  • Wenn man ihn gerade nicht brauchen. Kann später wieder aktiviert werden.

Steuern

  • Möglicherweise kann man Ausgaben für pre-prod Umgebungen als Forschungs und Entwicklungskosten absetzen.

EC2 Link zu Überschrift

  • gp2 benutzen - nicht io1 oder jetzt io2 - für fast alles. provisioned IOPS Maschinen sind teuer

  • Vielleicht sind Graviton-Instanzen eine Möglichkeit. Wenn der workload mit ARM kompatibel ist (das ist in 95% der Fälle gegeben), kann man hier rund 30 % einsparen.

Sind spot instances eine Option?

  • Wenn Unterbrechungen der Arbeit akzeptiert werden können
  • Es ist billiger als reserved instances und es gibt keine langfristige Verpflichtung.
  • Am besten auto scaling groups nicht nur mit einem Instanztyp betreiben sondern mit mehreren. Das erhöht die Wahrscheinlichkeit, dass spot instances verfügbar sind. (Statt eine xlarge Instanz können auch zwei large Instanzen laufen, wenn Parallelisierung gegeben ist)

Savings Plan

  • Flexibler: nicht an eine bestimmte Region oder Instanzfamilie gebunden
  • Gilt auch für Fargate
  • Reserved Instances können einen höheren Rabatt erhalten

Reserved Instances

  • Nicht zu viel am Anfang kaufen. Erstmal für 20% der benötigten Kapazität kaufen und nach ein paar Wochen nachkaufen.
  • Wenden Sie sich an den Support, wenn Sie zu viel gekauft haben, er kann Ihnen helfen.
  • Prüfen Sie konvertierbare Instanzen

Die richtige Größe Ihrer EC2-Instanzen (right-sizing)

Elastic Block Storage (EBS) Link zu Überschrift

  • Gibt es ungenutzte EBS-Volumes? Überdimensionierte Volumes? Unnötige Snapshots?

  • Updaten von gp2-Volumes auf gp3 kann bis zu 20% sparen.

Load Balancer Link zu Überschrift

  • Vielleicht reicht ein ALB für mehrere routes mit geringem Verkehr

RDS Link zu Überschrift

Cloudwatch Link zu Überschrift

  • Logging kann sehr teuer werden, nicht zu unterschätzen.

  • Gibt es eventuell externe Tools, die unnötigerweise Cloudwatch-Daten abrufen und Kosten verursachen?

  • Gibt es veraltete Logs, die gelöscht oder auf billigeren Speicher verschoben werden können (archiviert)?

  • Übermäßiges Logging in Anwendungen? (Vielleicht muss prod nicht auf info level loggen)

Lambda Link zu Überschrift

  • Eine Erhöhung des RAM kann die Kosten senken, wenn es die Laufzeit in einem höheren Mass senkt. Hier kann man sich mal den Lambda Power Tuner anschauen

  • EC2-services mit geringem Volumen auf Lambda umschreiben?

S3 Link zu Überschrift

  • Aktivieren von S3 analytics in den größten s3-Buckets.

  • Verwenden von lifecycle policies. Automatisiert das Verschieben von Daten in billigere tiers.

  • private endpoints benutzen, um die Datengebühren zu senken.

  • Daran denken, dass Anfragen (Datenverkehr) ein Vielfaches der Speicherkosten betragen können.

  • CloudFront benutzen, wenn Sie S3 außerhalb von AWS nutzen. Anfragen sind viel billiger.

  • S3 Storage Lens benutzen. Hier ist ein AWS Artikel wie man damit Kosten senkt.

  • Hier ist ein weiterer guter Artikel über S3-Kostenoptimierung.

Elastic Container Registry (ECR) Link zu Überschrift

  • Wenn man ECR verwenden und innerhalb eines privaten Subnetzes arbeiten, auf jeden Fall die Einrichtung von VPC-Endpunkten für ECR (und S3 für die image layers) in Betracht ziehen. Das Abrufen von images über ein NAT-Gateway wird sehr schnell sehr teuer.

DynamoDB Link zu Überschrift

  • On-Demand-Kapazität ist für tables, auf die weniger häufig zugegriffen wird, günstiger. Sichergehen, dass man dafür keine provisioned capacity benutzt (provisioned capacity ist oft der Standard, wenn man Terraform oder CDK verwenden).
  • Auch hier VPC endpoints in Betracht ziehen.

API-Gateway Link zu Überschrift

  • Wenn die API nur einen Proxy zu Lambda darstellt, geht es wahrscheinlich billiger. HTTP-API anstelle von REST kann Kosten um bis zu 70% zu senken.

Network Address Translation (NAT) Link zu Überschrift

  • Ein NAT-Gateway pro AZ erstellen, um die Kosten für AZ-übergreifenden Datentransfer zu reduzieren.

  • NAT-Gateways at scale sind extrem teuer (0,045 $ pro GB bei der Datenverarbeitung plus zwischen 0 und 0,09 $ pro GB, je nachdem, wohin die Daten gehen). Vielleicht machen NAT-Instanzen oder fck-nat Sinn.

  • Vielleicht kann Gateway-Endpunkte, Interface-Endpunkte oder öffentliche Subnetze anstelle von NAT verwenden?

  • Eventuell macht eine Konsolidierung von NAT-Gateways durch ein Egress-VPC und Transit-Gateways Sinn.

Step Functions Link zu Überschrift

Datenübertragung Link zu Überschrift

  • Verschaffen Sie sich einen Überblick über alle Datenübertragungskosten.

  • Für einen visuellen Überblick gibt es hier eine gute Grafik der Duckbill Group.

  • Im Kosten-Explorer wird es als ec2-other angezeigt.

  • Vermeiden von öffentlichen Netzwerkrouten für interne Ressourcen (vpc endpoints).

  • vcp flow logs einschalten und mit AWS Insights analysieren.

Regionen Link zu Überschrift

  • Am Besten workloads in einer oder zwei Regionen behalten, es sei denn, es gibt Gründe, die dagegen sprechen.

  • Einige Regionen sind billiger als andere. Wenn Latenzzeiten und Regulierungen kein Problem darstellen, macht es vielleicht Sinn z. B. nach Mumbai umzuziehen.

Externe Tools Link zu Überschrift

Info
Der Artikel wurde zuvor auf Englisch auf https://markpollmann.com veröffentlicht