AWS 2025: Was Sie zu wissen glauben – und was inzwischen falsch ist

 (lastweekinaws.com)
8 Punkte von GN⁺ 2025-08-21 | 3 Kommentare | Auf WhatsApp teilen
  • Die Kernservices von AWS entwickeln sich rasant weiter
  • Wichtige Funktionen wie EC2, S3, Lambda bieten heute eine Performance und Flexibilität, die die Erwartungen der Nutzer im Vergleich zur Vergangenheit übertreffen
  • Auch bei Networking, Authentifizierung und Kostensenkung gab es viele Änderungen und Optimierungen
  • Veraltete alte Blogposts oder Informationen können für Verwirrung sorgen
  • Um AWS effektiv zu nutzen, ist es essenziell, die neuesten Updates und geänderten Richtlinien zu kennen

AWS 2025: Gegenwart statt alter Annahmen

  • AWS ist eine Cloud-Plattform mit fast 20 Jahren Geschichte, und entsprechend verändern sich die „Selbstverständlichkeiten“ der Services ständig
  • So viele Kernfunktionen wurden verbessert, dass selbst erfahrene Nutzer mit dem Tempo der Änderungen kaum Schritt halten können
  • Es gibt weiterhin viele Blogposts mit veralteten Informationen, deshalb ist es wichtig, die tatsächlichen Änderungen bei der realen Konfiguration genau zu kennen

EC2

  • Security Groups und IAM-Rollen von EC2-Instanzen lassen sich jetzt ohne Unterbrechung ändern
  • Auf laufenden Instanzen können EBS-Volumes in der Größe geändert sowie an- und abgehängt werden
  • EC2-Instanzen lassen sich inzwischen erzwingend stoppen oder beenden, sodass man nicht mehr auf lange Timeouts warten muss
  • Die Funktion Live-Migration zwischen physischen Hosts wurde eingeführt, wodurch Warnungen vor Leistungsabfall von Instanzen selten geworden sind
  • Die Zuverlässigkeit von Instanzen ist deutlich gestiegen; dass Instanzen wie früher ohne Vorwarnung verschwinden, kommt kaum noch vor
  • Die Preisänderungen bei Spot-Instanzen erfolgen nun schrittweise, sodass man sie nicht mehr wie auf einem Handelsparkett in Echtzeit überwachen muss
  • Fälle, in denen dedizierte Instanzen erforderlich sind, sind äußerst selten geworden (auch eine HIPAA BAA ist dafür seit fast 10 Jahren praktisch nicht mehr nötig)
  • AMI Block Public Access ist in neuen Accounts standardmäßig aktiviert (Stand 2023 gilt dies auch für Accounts, die seit über 90 Tagen kein öffentliches AMI besitzen)

S3

  • S3 ist nicht mehr Eventually Consistent, sondern bietet Read-After-Write Consistency
  • Es ist nicht mehr nötig, den ersten Teil von Objekt-Keys zu randomisieren, wodurch Sorgen über Datenverteilung und Hotspots abnehmen
  • ACLs (Access Control Lists) werden nicht mehr empfohlen und sind bei neuen Buckets standardmäßig deaktiviert
  • Für neue Buckets ist Block Public Access standardmäßig aktiviert
  • Speicherverschlüsselung wird automatisch angewendet
  • Bevor Glacier eine Storage Class von S3 wurde, war es ein separater Service; heute ist es integriert, Spuren davon sieht man nur noch etwa in der Abrechnung
  • Kosten und Geschwindigkeit von Glacier-Restores sind im Vergleich zu früher deutlich besser vorhersagbar und günstiger geworden. Die früher gefürchteten Restore-Kosten entsprechen nicht mehr der Realität

Networking

  • EC2-Classic ist vollständig verschwunden
  • Öffentliche IPv4-Adressen sind jetzt nicht mehr kostenlos; es fallen dieselben Kosten an wie für Elastic IPs
  • Statt VPC Peering gibt es inzwischen bessere Optionen wie Transit Gateway, VPC-/Ressourcenfreigabe und Cloud WAN
  • Mit VPC Lattice und Tailscale lassen sich komplexe Networking-Probleme einfach lösen
  • Die Übernahmezeit für CloudFront-Updates wurde von 45 Minuten auf etwa 5 Minuten reduziert (bei wartenden CloudFormation-Deployments kann es sich aber weiterhin lang anfühlen)
  • Beim ELB Classic fielen Gebühren für Cross-AZ-Datentransfer an, während beim ALB nur LCU-Kosten berechnet werden. Beim NLB sind Cross-AZ-Gebühren weiterhin zu beachten
  • Network Load Balancer unterstützen jetzt Security Groups
  • Availability Zone IDs unterschieden sich früher je nach Account, doch jetzt lassen sich Zone IDs mit Resource Access Manager angleichen

Lambda

  • Bei Lambda wurde die 5-Minuten-Grenze auf 15 Minuten erhöht; außerdem kamen Unterstützung für Container-Images (Docker), EFS Shared Storage, bis zu 10 GB RAM und /tmp 10 GB hinzu
  • Die Aufrufgeschwindigkeit von Lambda innerhalb einer VPC wurde deutlich verbessert
  • Das Problem mit Cold Starts ist gegenüber früher stark entschärft worden

EFS

  • Die IO-Performance von EFS lässt sich jetzt unabhängig von der Kapazität steuern, sodass kein Speicherplatz mehr mit bedeutungslosen Daten gefüllt werden muss

EBS

  • Neue EBS-Volumes können sofort mit voller Performance genutzt werden, sofern keine Basisdaten vorhanden sind
  • Volumes, die aus Snapshots erstellt wurden, können beim ersten Lesen von Daten langsam sein; daher wird empfohlen, die gesamte Disk einmal zu lesen (schnellere Optionen stehen ebenfalls zur Verfügung)
  • io1-Volumes lassen sich gleichzeitig an mehrere EC2-Instanzen anhängen, werden in der Praxis aber nur für sehr spezielle Situationen empfohlen

DynamoDB

  • Leere Felder innerhalb von Items sind jetzt erlaubt
  • Die Performance ist deutlich gleichmäßiger geworden, sodass man Hot-Key-Probleme nicht mehr so häufig mit separaten Tools überwachen muss wie früher
  • Durch Änderungen beim Pricing ist für die meisten Nutzer der Typ On Demand sinnvoller

Kostensparoptionen

  • Reserved Instances werden schrittweise eingestellt, und Savings Plans sind der künftige Standard. Zwar ist der Rabatt von Savings Plans gegenüber RI gesunken, dafür ist die Flexibilität höher
  • EC2-Nutzung wird sekundengenau abgerechnet, sodass auch sehr kurz laufende Instanzen kosteneffizient sind
  • Cost Anomaly Detector erkennt unerwartete Nutzungsmuster mit hoher Genauigkeit und ist kostenlos
  • Compute Optimizer liefert verlässliche Empfehlungen für verschiedene Ressourcen wie EBS. Die Empfehlungen von Trusted Advisor sind dagegen noch immer nicht konsistent genug

Authentifizierung

  • Berechtigungen über IAM-Rollen werden empfohlen; IAM-Benutzer eignen sich nur noch für Legacy-Apps
  • IAM Identity Center ersetzt AWS SSO und wird für den Account-Zugriff verwendet. Das sorgt teilweise für Verwirrung
  • Für das Root-Konto können mehrere MFA-Geräte registriert werden
  • Für Mitgliedskonten in einer Organisation müssen keine separaten Root-Zugangsdaten mehr eingerichtet werden

Sonstiges

  • Die Zuverlässigkeit und Haltbarkeit von us-east-1 haben sich deutlich verbessert. Ausfälle, die früher häufig waren, sind heute bereits ein berichtenswertes Ereignis
  • Deprecations von AWS-Services sind weiterhin selten, nehmen aber zu; bei kleineren Services sollte man die Abhängigkeit daher im Blick behalten
  • Das Phänomen, dass der letzte Datenpunkt in CloudWatch-Daten aufgrund von Inkonsistenzen unnatürlich niedrig angezeigt wird, tritt nicht mehr auf
  • Das AWS-Konto von Mitgliedskonten innerhalb einer Organisation kann nun direkt vom Root-Konto aus geschlossen werden

Verwandte Beiträge

3 Kommentare

 
roxie 2025-08-23

Wow, da hat sich wirklich viel verändert.
 
howudoin 2025-08-23

AWS lässt sich inzwischen nicht mehr als einzelner Service auswählen und nutzen.
Wenn man irgendetwas machen will, muss man dies und das miteinander verknüpfen und einsetzen.
Es ist keineswegs einfach.
Wenn man es in einem Startup nutzen will, braucht man nicht nur Budget für Cloud-Kosten, sondern auch für DevOps-Personal.
Wenn man es richtig aufbauen will, wird der Arbeitsaufwand so stark größer, dass die Entwicklungszeit praktisch komplett darauf draufgeht.
Außerdem gibt es immer mehr Fälle, in denen Managed Services die bessere Wahl sind, sodass man schon auf Code-Ebene plattformabhängig wird.
 
GN⁺ 2025-08-21
Hacker-News-Kommentare
  • Zu sehen, dass bei S3 "Block Public Access" jetzt standardmäßig auf neue Buckets angewendet wird, halte ich für absolut richtig; es gab viele massive Datenlecks durch falsch konfigurierte S3-Buckets. Aber gelegentlich will ich einfach einen S3-Bucket mit öffentlicher Leseberechtigung erstellen, um Dateien öffentlich auszuliefern, und jedes Mal hat sich wieder irgendetwas geändert, sodass das alte Rezept nicht mehr funktioniert und ich alles von Grund auf neu lernen muss.
    • Ich würde sagen: Schaut euch die Einstellung "Block Public Access" genau an. Sie ist eine Art Sicherheitsgeländer, das verhindern soll, dass Leute große Fehler machen. Selbst wenn man eine sehr schlampige Bucket-Policy oder ACLs konfiguriert (veraltet, aber immer noch in Benutzung), ist öffentlicher Zugriff unmöglich, solange Block Public Access aktiviert ist. Umgekehrt ist es auch okay, Block Public Access zu deaktivieren und eine sehr sauber entworfene Bucket-Policy zu verwenden. Die Bucket-Policy entscheidet vollständig darüber, wer zugreifen kann. Natürlich kann sich so eine Policy langfristig versehentlich ändern, es können unerwartet IAM-Rollen hinzukommen oder Trust Policies angepasst werden, daher ist gutes Change-Management wichtig.
    • In solchen Situationen nutze ich oft ein LLM. Ich lasse die Dokumentation lesen und bitte darum, Demo-Code herauszuziehen, der quer über die offizielle AWS-Dokumentation verstreut ist. Wenn ich das habe, frage ich direkt nach den gewünschten Anpassungen.
    • Dabei habe ich so ein Déjà-vu-Gefühl, als hätte es das schon einmal gegeben. Ich meine, vor 10 Jahren haben doch auch alle ihre Buckets offen stehen lassen, weshalb solche Maßnahmen eingeführt wurden.
    • Durch solche Änderungen wird die Interviewfrage „Kennen Sie sich mit dieser Technologie aus?“ sehr schwammig. Die Technik ändert sich jeden Monat, da möchte man fast fragen: bezogen auf welchen Zeitpunkt?
    • Wer es offiziell lernen will, darf 250 $ bezahlen und gleich noch eine Zertifizierungsprüfung ablegen.
  • Dass man bei EC2 Sicherheitsgruppen oder IAM-Rollen austauschen kann, ohne die Instanz zu beenden, geht schon seit Jahren. Spot Instances waren früher ein Bietermarkt, aber heute gibt es das Bieten gar nicht mehr; dadurch sind starke Preisschwankungen oder Fälle, in denen nur bestimmte Nutzer Zugriff haben, verschwunden, was viel besser ist. Und früher hieß es, man müsse den Anfang von Objektschlüsseln zufällig machen, um Hotspots zu vermeiden, aber das ist heute nicht mehr nötig. Es hat eine Weile gedauert, meine Kollegen davon zu überzeugen, doch die speicherten ohnehin nur winzige Dateien, die nichts mit Backend-Engpässen bei S3 zu tun hatten. Lambda hatte früher ein Limit von 5 Minuten und unterstützte keine Container-Images; heute gibt es 15 Minuten Laufzeit, Docker-Images, geteiltes EFS, bis zu 10 GB RAM und bis zu 10 GB /tmp-Speicher. Ich habe dabei auch gelernt, dass der globale Scope von Python genau wie /tmp erhalten bleiben kann.
  • Glacier-Wiederherstellungen müssen sich inzwischen nicht mehr schmerzhaft langsam anfühlen. Im typischen Amazon-Stil hatte ich früher die Vermutung, dass Glacier tatsächlich irgendwo in einem echten Amazon-Lagerhaus lief: Man fordert Daten an, und ein Mitarbeiter holt ein Wechselmedium aus dem Regal und steckt es in einen Server. Das wirkte ähnlich wie Bandsicherungen bei alten Time-Sharing-Computern, bei denen man die Bänder physisch tauschen musste.
    • Tatsächlich wurden wahrscheinlich automatisierte Systeme wie Bandroboter verwendet, hier ein passendes Beispielbild. Ein Roboter holt das Band, legt es ins Laufwerk, spult zur passenden Stelle, liest es und spult es anschließend zurück und räumt es wieder ein. Die Wartezeit entsteht durch das Suchen des Bands, das Zurückspulen und die Wartezeit auf ein freies Laufwerk. Vermutlich wurde aus Effizienzgründen alles abgearbeitet, was auf einem einmal eingelegten Band angefordert war, bevor es wieder entfernt wurde.
    • Über Interna kann ich nichts offenlegen, aber ich habe noch niemanden gesehen, der das Design von Glacier exakt erraten hätte. Ich war früher selbst bei AWS, und ich kann sagen, dass Glacier wie andere AWS-Services in denselben Rechenzentren betrieben wurde. In Engineering und Produktmanagement ist es wichtig, die Erwartungen der Kunden gut zu steuern. Wenn man sagt, das Upload-Limit liegt bei 10, dann aber 12 zulässt, erwarten Kunden fortan 12. Erwartungsmanagement ist entscheidend.
    • Da Festplatten einheitlich sind, denke ich, dass Lagerhäuser mit automatischen Robotern betrieben werden. Menschen braucht man eher für nicht standardisierte Dinge mit unterschiedlichen Größen und Formen.
    • Solche Anlagen sind jedenfalls schon seit Jahrzehnten automatisiert.
  • Ich kann mich nicht mehr bei meinem AWS-Konto anmelden, weil ich MFA nicht vorher eingerichtet habe. Und um ein Gerät ausgestellt zu bekommen, muss man sich zuerst anmelden. Ich wurde vorher zwar gewarnt, aber dass man ein MFA-Gerät nicht ohne Login beantragen kann, ist schon ziemlich frustrierend.
    • Ich würde empfehlen, den Support zu kontaktieren.
      AWS Support kontaktieren
    • Das sieht nach einem Problem aus, das der Support leicht lösen können sollte.
  • Ich vermute, viele denken ähnlich wie ich: Statt weiter den klassischen AWS-Weg mit API Gateway, serverlosen Lambdas und IAM-Rollen bis ins Detail passend zu machen, möchte man es inzwischen einfach lassen und nur noch EC2 oder einen LightSail-VPS, einen S3-Bucket und Route53 für die Domain-Anbindung nutzen und sich um den Rest nicht kümmern.
    • Wenn man nur Storage + VPS nutzt, ist ein klassischer VPS deutlich günstiger als AWS. Meine Haltung ist eher: Wenn man schon AWS verwendet, dann richtig und umfangreich. Alles, was delegierbar ist, sollte man an Amazon abgeben, um Effizienz und Kosten zu optimieren. Step Functions, Lambda und DynamoDB waren den Alternativen oft überlegen. Allerdings habe ich den Eindruck, dass Entwickler die Optimierung auf den jeweiligen Anbieter hin schlechter beherrschen, als man erwarten würde.
    • Tatsächlich haben viele in der Branche ihre Cloud-Nutzung vereinfacht, unter anderem wegen regionaler Beschränkungen der Services oder besser vorhersagbarer Rechnungen.
    • IAM-Management frisst so viel Zeit, dass es sich anfühlt, als würde die Zeit, die früher in Systemadministration ging, jetzt komplett in Berechtigungsverwaltung fließen. IAM ist so schwierig, dass es in der Praxis netto eher ein Verlust ist. Irgendwo zwischen VPS und übertriebener Least-Privilege-Verwaltung im Serverless-Stil dürfte ein Sweet Spot liegen. Fargate könnte ein Kandidat sein; ich will damit weiter experimentieren.
  • Ich wünschte, AWS würde sich stärker auf die „grundlegenden, aber wichtigen Services“ konzentrieren, die sie bisher gut beherrscht haben, statt im KI-Bereich hektisch überall mitziehen zu wollen und alles Mögliche auf den Markt zu werfen. Die AWS-Führung wirkt bei GenAI orientierungslos, auch wenn sie die zugrunde liegende Infrastruktur gut bauen. Durch den AI-Fokus wirkt alles panisch und für Kunden unnötig zerstreut.
    • Die aktuelle Führung scheint darauf hinzuarbeiten, Infrastruktur so bereitzustellen, dass jeder einfach ein Modell auswählen und sofort nutzen kann — ohne kompliziertes Setup.
  • Es ergibt wirklich keinen Sinn, dass bei einem S3-Bucket in derselben Region wie die VPC NAT-Gateway-Kosten anfallen, wenn der Zugriff über das öffentliche Internet läuft. Der Standard sollte hier ein opt-out sein, nicht opt-in. Dass opt-in der Standard ist, liegt meiner Meinung nach wohl daran, dass AWS über diese Architektur zusätzliche Einnahmen erzielt. Kaum jemand wird den aktuellen Pfad absichtlich wollen.
    • Das ist so entworfen, weil Sicherheit der Standard ist. Wenn man kein NAT Gateway, keinen VPC Gateway Endpoint (S3) und keinen anderen Internet-Ausgang einrichtet, kann die Workload nicht auf S3 zugreifen. Netzwerke sollten standardmäßig geschlossen sein. Wenn Nutzer nicht verstehen, welchen Pfad ihr Traffic nimmt, und dann etwas bauen, liegt die Verantwortung beim Kunden. AWS sollte man als Anbieter roher Infrastructure as a Service (IaaS)-Werkzeuge betrachten.
    • Genau dafür gibt es den S3 VPC Gateway Endpoint. Er ist sogar kostenlos.
      Offizielle AWS-Dokumentation
    • Wenn man VPC, Subnetze, PrivateLink-Endpunkte usw. einmal komplett eingerichtet hat, wirkt das wirklich absurd. Schon in die Benennung „PrivateLink“ wurde viel Mühe gesteckt (technisch hat der Name auch Bedeutung), aber so etwas sollte von Anfang an ohne Setup einfach vorhanden sein. Vor allem, wenn man private Subnetze nutzt, ist PrivateLink für den Zugriff auf Dinge wie S3 doch praktisch die einzige Methode, was seltsam wirkt.
    • Ich finde, VPC-Endpunkte sollten grundsätzlich kostenlos und standardmäßig aktiviert sein. Es ist schon heftig, für die Nutzung der API des eigenen Dienstanbieters zusätzlich zahlen zu müssen.
    • Das dient der Preisdifferenzierung. Kunden, die nicht preissensibel sind, kümmern sich nicht darum. Die anderen bemühen sich, Kosten zu senken, und selbst dann gibt es oft Situationen, in denen man AWS trotzdem verwenden muss.
  • Dieser Artikel hat mich beruhigt. Ich habe immer Sorge, dass Amazon etwas Großes ändert und Migrationen erzwingt, aber seit 2013 konnte ich meine EC2-Instanzen fast ohne Verwaltungsaufwand gut nutzen. Gut, dass es keine unerwarteten Änderungen gab.
  • Dass Availability Zones früher pro Konto zufällig gemappt wurden, finde ich rückblickend schockierend.
    • Das diente dem Load Balancing. Wenn viele Konten immer dieselbe AZ wie etwa 1b ausgewählt hätten, sollte die physische Verteilung trotzdem gleichmäßiger ausfallen. Später wurden kanonische Namen pro AZ eingeführt; vermutlich, weil die Konten, die tatsächlich Hotspots verursachten, andere waren als diejenigen, die die Metadaten brauchten.
    • Ich denke, das sollte verhindern, dass in der Standardeinstellung alle einfach us-east-1a auswählen und damit eine einzelne AZ überlasten.
    • Anfangs war das gut für die Lastverteilung, aber bei Netzwerkverbindungen zwischen mehreren Konten (PrivateLink usw.) war es verwirrend, weil man jedes Mal prüfen musste, welche AZ womit korrespondiert. Deshalb haben wir sogar eine Methodik für 1:1-Mappings zwischen Konten und eine interne Nachschlagetabelle aufgebaut. Später hat AWS dann Zone-IDs in die Metadaten aufgenommen, sodass man das leicht abfragen konnte.
    • Diese Richtlinie hat mir wirklich viel Ärger gemacht.
  • Ich möchte etwas richtigstellen: Bedeutungsloses Trivia-Wissen kann komplett auf den Kopf gestellt werden.
    Weird Al: Everything You Know is Wrong
    Firesign Theatre: Everything You Know is Wrong