In der Woche vom 14. September hat AWS Platform Engineering als Produkt verkauft: Elastic Beanstalk Cluster Mode setzt ein Portfolio von Anwendungen auf geteiltes, vollständig verwaltetes EKS, und die neue Getting-Started-Erfahrung gibt einem neuen Builder ein vorkonfiguriertes Projekt statt eines leeren Accounts. Darunter wurde das Compute in zwei Richtungen günstiger (T8i-Instances, ARM64 in ECS Express Mode), PrivateLink hat einen Tunnel-Endpunkt zum Teilen ganzer Netzsegmente bekommen, und zwei Identitätsänderungen sind gelandet, die dein Monitoring leise kaputtmachen, wenn du sie ignorierst. Migrationstooling war diese Woche ruhig (nichts von AWS Transform oder DMS), also führt die Plattformgeschichte.

Elastic Beanstalk Cluster Mode: das PaaS-Argument, noch einmal

Am 17. September hat AWS Elastic Beanstalk Cluster Mode eingeführt: Mehrere Anwendungen laufen auf geteilter Infrastruktur, angetrieben von Amazon EKS, vollständig verwaltet, mit einer betrieblichen Baseline. Du lädst Quellcode in Java, .NET, Python, Node.js, PHP, Ruby oder Go hoch (oder ein Dockerfile, oder ein Image), Beanstalk containerisiert ihn bei Bedarf mit Cloud Native Buildpacks, und die Umgebung bekommt Traffic-Shifting-Deployments mit automatischem Rollback, ereignisgesteuertes Autoscaling, Secrets-Manager-Integration, OpenTelemetry-Observability und KI-gestütztes Troubleshooting. Standard- und Cluster-Mode-Umgebungen koexistieren in derselben Anwendung, du migrierst also eine Umgebung auf einmal.

Das Kostenargument pro Anwendung ist das, mit dem jedes interne Plattform-Team einen geteilten EKS-Cluster finanziert hat. Der Unterschied ist, wer ihn betreibt: AWS, für die Lebensdauer des Workloads, und du siehst nie einen Node, eine kubeconfig oder ein Upgrade-Fenster.

Mit zwanzig kleinen Services und ohne Appetit auf Kubernetes ist Cluster Mode wahrscheinlich der richtige Default. Wenn du ein Plattform-Team hast, das EKS bereits besitzt, konkurriert Cluster Mode mit ihm um dieselben Workloads und bietet weniger Kontrolle: keine eigenen Admission Policies, kein Node-Tuning, keine Wahl des CNI. Der Failure Mode ist der, den geteilte Plattformen immer haben, ein Baseline-Upgrade, das für neunzehn Anwendungen richtig und für die zwanzigste falsch ist, nur dass die zwanzigste jetzt nichts pinnen kann. Pilotiere es mit den Anwendungen, über die du gern die Kontrolle abgeben würdest.

Günstigeres Compute, auf zwei Wegen

Am 17. September sind EC2 T8i-Instances generally available geworden: Custom Intel Xeon 6 der sechsten Generation, Nitro-Karten der sechsten Generation, vier Größen (nano, micro, small, medium), bis zu 30 % besseres Preis-Leistungs-Verhältnis als T3, bis zu 70 % mehr Compute, 1,25x die Netzwerkbandbreite, 2,4x die EBS-Bandbreite. Dasselbe CPU-Credit-System mit Standard- und Unlimited-Modus, der Umzug von T3 ist also eine Änderung des Instance-Typs und sonst nichts. t8i.micro und t8i.small sind im Free Tier.

Am 18. September hat ECS Express Mode ARM64 als CPU-Architektur hinzugefügt, sodass der Pfad "gib mir eine URL für dieses Image" auf Graviton landen kann, das AWS mit bis zu 40 % besserem Preis-Leistungs-Verhältnis als x86 angibt. Konfigurierbar für neue und bestehende Express-Mode-Services über Console, CLI, SDK und IaC.

Beides spart nur Geld, wenn jemand die Änderung macht. Die T3-Flotte in den meisten Accounts besteht aus Bastions, Build-Runnern und vergessenen internen Tools; eine Terraform-Variablenänderung und ein Instance Refresh sind der ganze Job. Für Express Mode ARM64 ist die Voraussetzung ein Multi-Arch-Image, und der Failure Mode ist ein Basis-Image oder eine native Abhängigkeit, die nur amd64 ausliefert. Baue mit docker buildx build --platform linux/amd64,linux/arm64, lass die Manifest-Liste die Arbeit machen und schalte dann die Architektur um.

PrivateLink Tunnel Endpoints: teile ein CIDR, nicht einen Service

Am 18. September hat AWS PrivateLink Tunnel Endpoints angekündigt, einen neuen VPC-Endpunkt-Typ. Bisher bedeutete das Teilen von Ressourcen mit einer externen Partei eine Resource Configuration pro Ressource. Jetzt kann eine Resource Configuration einen CIDR-Bereich in deinem Netz repräsentieren; du teilst sie über AWS RAM, und die andere Seite erstellt einen Tunnel-Endpunkt und nutzt GENEVE-Kapselung, um alles innerhalb dieses Bereichs zu erreichen. Stundengebühr pro Tunnel-Endpunkt plus eine Gebühr pro verarbeitetem GB.

Das füllt die Lücke zwischen PrivateLink (ein Service, ein Endpunkt, keine Routing-Exposition) und Transit Gateway oder Peering (volles Routing, in beide Richtungen, und eine CIDR-Verhandlung). Ein Vendor, der vierzig Hosts in deinem Management-Subnetz braucht, hat früher die schwergewichtige Option erzwungen; jetzt bekommt er einen Tunnel in genau den Bereich, den du benannt hast.

Die Gebühr pro GB macht das zu einem Control-Plane-Pfad, nicht zu einem für Massendaten; modelliere die Kosten, bevor jemand Backups hindurch routet. Und "ein CIDR-Bereich" ist eine breitere Gewährung als "ein Service": Die Security-Group- und NACL-Disziplin innerhalb dieses Bereichs ist jetzt Teil deiner externen Angriffsfläche, also behandle den Bereich, den du exponierst, als DMZ und dimensioniere ihn entsprechend.

Zwei Identitätsänderungen, die Dashboards kaputtmachen

Am 14. September hat das Root-User-Sign-in angefangen, auch aus US East (Ohio) und US West (Oregon) bedient zu werden, nicht nur aus N. Virginia, mit über alle drei verteiltem Traffic. Gut für die Resilienz, aber das CloudTrail-Event ConsoleLogin für ein Root-Sign-in wird jetzt in der Region aufgezeichnet, die es verarbeitet hat. Wenn dein Root-Login-Alarm ein Metric Filter auf einem us-east-1-Trail ist, fängt er jetzt etwa ein Drittel der Root-Logins. Verschiebe ihn auf einen Organization Trail oder ergänze die anderen beiden Regionen noch diese Woche.

Am 15. September hat STS seine Session-Token-Limits zu einem einzigen 4.096-Byte-Limit zusammengelegt und damit getrennte Obergrenzen für Token-Größe und für übergebene Session Policies und Tags ersetzt. STS gibt jetzt die Token-Größe und die prozentuale Auslastung zurück, loggt sie nach CloudTrail und veröffentlicht CloudWatch-Metriken; ein neuer optionaler Parameter erzeugt absichtlich große Tokens, damit du testen kannst, ob deine Proxies und Header sie überleben. Wenn du je "packed policy too large" gesehen hast, ist das der Fix, und der Testparameter beweist, dass dein Stack die Obergrenze verkraftet, bevor ein Session Tag dich hineindrückt.

Auch diese Woche

Der rote Faden

Cluster Mode und die neue Builder-Erfahrung sind dasselbe Produkt in zwei Größenordnungen: AWS wählt die Defaults und übernimmt die betriebliche Verantwortung, die damit kommt. Der Preis ist, dass für alle gewählte Defaults zu niemandem perfekt passen, und die Stellen, an denen das beißt (Node-Tuning, ein Root-Login-Alarm, der eine Region angenommen hat, ein Session Token, das zwei Limits angenommen hat), sind genau die Stellen, die die kleineren Launches dieser Woche berührt haben. Die Plattformarbeit verschwindet nicht, wenn AWS die Plattform betreibt; sie wandert vom Bauen der Sache zum Wissen, welche ihrer Defaults für dich falsch sind.

Lies das als Nächstes

Für die KI- und Agenten-Lesart derselben Woche siehe ercan.ai. Wenn dein Team Hands-on-Hilfe bei AWS, Cloud-Architektur, CI/CD-Pipelines, Linux, GitHub oder GitLab und der Plattformarbeit darum herum braucht, lebt die Consulting-Seite auf ercanermis.com.

Referenzen