Aurora Serverless v2 nach sechs Monaten: die 0,5-ACU-Untergrenze und der Auto-Pause-Mythos

Veröffentlicht im TEN INVENT Blog · September 2026

Aurora Serverless v2 wird mit einem Satz verkauft: zahlen Sie für die Datenbankkapazität, die Sie nutzen, skaliert in Sekundenbruchteilen. Sechs Monate Betrieb in Produktion, Staging und Dev für die Plattform eines US-Kunden haben uns gelehrt, dass der Satz wahr ist und dass er zwei Fragen verbirgt, die entscheiden, ob es die richtige Datenbank für Sie ist: welche Kapazität ist die kleinste, die Sie nutzen dürfen, und was passiert, wenn Sie gar keine nutzen.

Kurzfassung: es ist die richtige Wahl für Dev und Staging, für Produktions-Workloads mit Lastspitzen und für alle, die lieber nicht über Instanzklassen nachdenken. Es ist die falsche Wahl für eine kleine, gleichmäßige Produktionslast, wo eine langweilige RDS-Instanz günstiger ist, und für eine große, gleichmäßige, wo provisioniertes Aurora günstiger ist. Für dieses Projekt würden wir es wieder wählen. Hier die Rechnung.

Was eine ACU ist, und was 0,5 davon kauft

Eine Aurora Capacity Unit entspricht grob 2 GiB Arbeitsspeicher mit proportionaler CPU und Netzwerkleistung. Sie setzen ein Minimum und ein Maximum pro Cluster, und der Cluster skaliert dazwischen je nach Last. Der Preis gilt pro ACU-Stunde: $0,12 in us-east-1, sodass eine ACU den ganzen Monat etwa $88 kostet und eine halbe ACU etwa $44.

Das Minimum lag früher bei 0,5 ACU, Punkt. Seit Ende 2024 können Sie es auf 0 setzen, was Auto-Pause aktiviert: nach einer konfigurierbaren Leerlaufzeit stellt der Cluster die Compute-Abrechnung ein und nimmt bei der nächsten Verbindung wieder den Betrieb auf. Das ist das Feature, das das Marketing meint, wenn es „pay for what you use“ sagt. Es ist auch der Ort, an dem die Nuance lebt.

In Dev und Staging setzen wir Minimum 0. Die Cluster pausieren über Nacht und am Wochenende, und ein Wiederanlauf dauert etwa 15 Sekunden. Der erste Request nach einer Pause wartet, oder scheitert und wird wiederholt, und das ist in Ordnung für eine Umgebung, in der der erste Request des Morgens von einem Entwickler kommt. Zwei Nicht-Produktions-Cluster gingen von etwa $90 im Monat bei je 0,5 ACU auf etwa $20.

In Produktion können wir das nicht. Ein 15-Sekunden-Stillstand beim ersten Request nach einer ruhigen Phase ist auf einer Consumer-App ein für Nutzer sichtbarer Ausfall, und er würde außerdem den App-Runner-Health-Check scheitern lassen, der die Datenbank trifft. Also läuft Produktion mit Minimum 0,5 ACU, rund um die Uhr, ob jemand die Anwendung nutzt oder nicht. Das ist die Untergrenze: $44 im Monat vor der ersten Abfrage. Die meiste Zeit liegt unser Produktions-Cluster zwischen 0,5 und 1,5 ACU, und die monatliche Compute-Rechnung landet bei etwa $90.

Das Gute

Die Skalierung ist echt und schnell. Ein nächtlicher Batch-Job, der den Großteil der Bestelltabelle anfasst, bringt den Cluster in unter einer Minute von 0,5 auf 4 ACU und in den folgenden fünfzehn wieder herunter. Wir haben nie eine Instanz dafür dimensioniert. Auf provisioniertem RDS würden wir die Spitze des Batch-Jobs den ganzen Tag bezahlen.

Es ist Postgres. Extensions, pg_dump, jedes ORM, jedes Tool. Die Data API und IAM-Authentifizierung sind da, wenn Sie sie wollen; wir nutzen IAM-Auth aus Lambdas und sparen uns dort die Passwortverwaltung.

Speicher ist getrennt und langweilig. $0,10 pro GB-Monat, wächst automatisch, kein Volume zum Vergrößern, keine IOPS zum Provisionieren. Backups innerhalb des Aufbewahrungsfensters sind inklusive.

Auto-Pause in Nicht-Produktion ist ein echtes Kostenfeature. Zwei Cluster, $70 im Monat gespart, keine Konfiguration außer einem Minimum von 0 und einem Leerlauf-Timeout. Es hat Preview-Umgebungen pro PR praktikabel gemacht: ein geteilter pausierter Cluster, eine Datenbank pro PR, keine Compute-Kosten pro PR.

Das Schlechte

Die Untergrenze ist der Preis. Für eine kleine Produktionslast sind 0,5 ACU rund um die Uhr $44 plus Speicher. Eine RDS-PostgreSQL-Instanz db.t4g.medium mit 2 vCPU und 4 GiB kostet etwa $47 On-Demand und $30 reserviert, sie skaliert nicht, und sie muss es auch nicht. Wenn Ihre Produktionslast gleichmäßig und klein ist, ist Serverless v2 der teurere Weg, dasselbe zu kaufen.

Herunterskalieren ist langsam, und beim Herunterskalieren fallen Verbindungen weg. Kapazität steigt in Sekunden und sinkt in Minuten, absichtlich. Wenn sie sinkt, schrumpft der Speicher der Instanz, und Verbindungen mit großen Working Sets werden beendet. Wir sahen eine Woche lang sporadische connection reset-Fehler, bevor wir sie mit Scale-in-Ereignissen korrelierten. RDS Proxy davor behob es für die Lambdas; für App Runner setzten wir das Idle-Timeout des Pools unter das Scale-in-Intervall.

Die maximale ACU ist ein Speicherlimit, das Sie im falschen Moment treffen können. Wir setzten max 4, um Kosten zu deckeln. Eine Reporting-Abfrage, die mehr Speicher brauchte, als 4 ACU liefern, wurde nicht langsamer, sie scheiterte. Auf provisioniertem RDS hätte dieselbe Abfrage geswappt und gekrochen, was wohl schlimmer ist, aber sie wäre fertig geworden.

Der Wiederanlauf nach Auto-Pause dauert nicht für alle 15 Sekunden. Es sind 15 Sekunden für den Cluster. Addieren Sie den Lambda-Kaltstart davor und den Verbindungspool der App-Runner-Instanz, der sich neu aufbaut, und der erste Morgen-Request in Dev kann 30 Sekunden dauern. Dort akzeptabel. Kein Produktionsfeature, was auch immer die Preisseite andeutet.

Die Kosten, ehrlich

Der Vergleich, den die Leute wollen, ist Serverless v2 gegen die Alternativen bei gegebener Durchschnittslast. Zum Listenpreis in us-east-1, nur Compute:

Der Schnittpunkt ist klar. Unter etwa 1 ACU Durchschnitt ist eine kleine RDS-Instanz günstiger oder gleich. Über etwa 2 ACU gleichmäßig ist provisioniertes Aurora günstiger. Serverless v2 gewinnt in der Mitte, und es gewinnt deutlich, wenn die Spitze ein Vielfaches des Durchschnitts ist, was die letzte Zeile ist und die meisten echten Anwendungen mit Nutzern in einer Zeitzone beschreibt.

Einstellungen, die wir in jeden neuen Cluster kopieren würden

• Produktion: min 0,5, max nach der größten Abfrage, die Sie je gesehen haben, plus eins, nicht nach dem Budget. Löschschutz an. RDS Proxy für alles Lambda-Förmige.
• Nicht-Produktion: min 0, Auto-Pause nach 10 Minuten, max 2. Den morgendlichen Stillstand akzeptieren.
• Beide: Idle-Timeout des Verbindungspools unter 5 Minuten, damit Scale-in-Ereignisse Sie nicht überraschen. I/O-Optimized-Speicher nur, wenn I/O-Gebühren etwa 25 % der Rechnung überschreiten, was bei uns nicht der Fall ist.
• ServerlessDatabaseCapacity und ACUUtilization in CloudWatch beobachten. Letztere mehr als ein paar Minuten bei 100 % bedeutet, dass max ACU zu niedrig ist und gleich etwas scheitert statt langsamer zu werden.

Fazit

Die Preisseite sagt: zahlen Sie für das, was Sie nutzen. Die genaue Version lautet: zahlen Sie in Produktion für mindestens eine halbe ACU, zahlen Sie anderswo nichts, wenn pausiert, und zahlen Sie einen Aufschlag pro ACU dafür, nichts dimensionieren zu müssen. Ob dieser Aufschlag sich lohnt, hängt ganz von der Form Ihrer Last ab, und jetzt haben Sie die Tabelle.

Sie wählen zwischen Serverless v2, RDS und provisioniertem Aurora für etwas Echtes? Wir rechnen es mit Ihnen durch.