Cloud | The .NET Blog

Azure Developer CLI (azd) April 2026 Updates

Emiliano Montesdeoca — Fri, 08 May 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Azure Developer CLI (azd) veröffentlichte fünf Releases im April 2026 (1.23.14 bis 1.24.2). Das große Thema: Hooks, die jetzt in Python, JavaScript, TypeScript und .NET ausgeführt werden – nicht mehr nur in Bash und PowerShell.

Mehrsprachige Hooks in azure.yaml

Hooks können nun neben Shell-Skripten auf .py-, .js-, .ts- oder .cs-Dateien verweisen. Jede Sprache erhält eine automatische Abhängigkeitsauflösung:

Python — erkennt requirements.txt oder pyproject.toml, erstellt ein Virtualenv und installiert Abhängigkeiten vor der Ausführung. Den Namen der Umgebung konfiguriert man mit virtualEnvName.
JavaScript / TypeScript — erkennt package.json und führt automatisch npm install aus. TypeScript wird über npx tsx ausgeführt, ohne Compile-Schritt. Den Paketmanager wählt man über den Konfigurationsblock packageManager.
.NET — führt .cs-Dateien mit dotnet run aus. Single-File-Skripte werden auf .NET 10+ unterstützt. Das Ziel-Framework wird über den Block configuration/framework konfiguriert.

Teams, die bereits in einer dieser Sprachen arbeiten, müssen keinen separaten Bash- oder PowerShell-Hook mehr pflegen, nur um Lifecycle-Events des Provisionierens zu verbinden.

azd update geht in die öffentliche Vorschau

azd update ist jetzt auf allen Plattformen in der öffentlichen Vorschau. Ein einzelner Befehl übernimmt das Update, unabhängig davon, wie azd ursprünglich installiert wurde – kein manuelles Nachverfolgen von Homebrew-, WinGet- oder MSI-Pfaden mehr.

Nicht-interaktiver Modus via AZD_NON_INTERACTIVE

Das Setzen von AZD_NON_INTERACTIVE=true (oder --non-interactive / --no-prompt) erzeugt nun konsistente, deterministische Fehler in CI/CD-Pipelines, wenn eine erforderliche Eingabe nicht automatisch aufgelöst werden kann. Zuvor war das Verhalten befehlsübergreifend inkonsistent.

KI-Modell-Quota-Preflight-Check

azd provision validiert die Azure Cognitive Services Quota, bevor KI-Modellressourcen bereitgestellt werden. Deployments, die aufgrund von Quota-Grenzen scheitern würden, zeigen den Fehler jetzt früh im Prozess an – nicht erst in der Mitte des Provisionierens.

„Diesen Fehler beheben" in der Copilot-Fehlerbehebung

Die azd-Copilot-Integration zur Fehlerbehebung gewinnt die Fähigkeit, einen vorgeschlagenen Fix direkt anzuwenden – nicht nur zu beschreiben. Wenn der Agent ein behebbares Problem erkennt, kann er die Änderung direkt vornehmen.

Benutzerdefinierte Provisionierungsanbieter und Key Vault Secret Resolver

Erweiterungsautoren können nun alternative Infrastruktur-Backends mit WithProvisioningProvider() registrieren. Außerdem löst azd @Microsoft.KeyVault(...)-Referenzen automatisch auf, bevor die Konfiguration an Erweiterungen übergeben wird – manuelle Secret-Auflösung in benutzerdefinierten Anbietern entfällt.

Ausschlüsse für Templates und Watch-Modus

Zwei neue Ignore-Dateien bieten feinere Kontrolle über die Dateiverarbeitung:

.azdignore — schließt beitragerspezifische Dateien (Dokumentation, CI-Konfigurationen) aus Template-Kopien aus, damit Endnutzer ein sauberes Projektgerüst erhalten.
.azdxignore — schließt Verzeichnisse aus, die während azd x watch Rebuilds auslösen, und reduziert so Lärm bei der iterativen Entwicklung.

Reserved-Name-Preflight und docker.network-Option

azd warnt nun, wenn vorhergesagte Ressourcennamen reservierte Azure-Wörter (MICROSOFT, WINDOWS oder das Präfix LOGIN) enthalten – bevor die Provisionierung beginnt. Eine neue docker.network-Option übergibt --network an docker build, was in Unternehmens-Proxy-Umgebungen nützlich ist, die ein bestimmtes Docker-Netzwerk erfordern.

Sicherheitsfixes

Das Windows-MSI-Paket enthält jetzt eine Code-Signing-Verifizierung. Ein weiterer Fix schließt ein Environment-Variable-Leak, das Werte über Erweiterungsbefehlsgrenzen hinweg hätte offenlegen können.

Ein intensiver Monat – der mehrsprachige Hook-Support beseitigt insbesondere einen echten Reibungspunkt für Teams, die nicht hauptsächlich in Bash arbeiten. Die vollständigen Release Notes enthalten das komplette Changelog aller fünf Releases.

Deine KI-Experimente auf Azure verbrennen Geld — So behebst du das

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Wenn du gerade KI-gestützte Apps auf Azure baust, ist dir wahrscheinlich etwas aufgefallen: Deine Cloud-Rechnung sieht anders aus als früher. Nicht nur höher — seltsamer. Sprunghaft. Schwer vorhersagbar.

Microsoft hat gerade einen großartigen Beitrag über Cloud-Kostenoptimierungsprinzipien, die immer noch wichtig sind veröffentlicht, und ehrlich gesagt könnte das Timing nicht besser sein. Denn KI-Workloads haben die Spielregeln bei den Kosten verändert.

Warum KI-Workloads anders zuschlagen

Hier ist die Sache. Traditionelle .NET-Workloads sind relativ vorhersagbar. Du kennst deinen App-Service-Tier, du kennst deine SQL-DTUs, du kannst die monatlichen Ausgaben ziemlich genau abschätzen. KI-Workloads? Nicht so sehr.

Du testest mehrere Modelle, um zu sehen, welches passt. Du fährst GPU-gestützte Infrastruktur für Fine-Tuning hoch. Du machst API-Aufrufe an Azure OpenAI, bei denen der Token-Verbrauch je nach Prompt-Länge und Benutzerverhalten stark variiert. Jedes Experiment kostet echtes Geld, und du führst vielleicht Dutzende durch, bevor du den richtigen Ansatz findest.

Diese Unvorhersehbarkeit macht Kostenoptimierung kritisch — nicht als Nachgedanke, sondern von Tag eins an.

Management vs. Optimierung — kenne den Unterschied

Eine Unterscheidung aus dem Artikel, die Entwickler meiner Meinung nach übersehen: Es gibt einen Unterschied zwischen Kosten-Management und Kosten-Optimierung.

Management bedeutet Tracking und Reporting. Du richtest Budgets in Azure Cost Management ein, bekommst Benachrichtigungen, siehst Dashboards. Das ist die Grundlage.

Optimierung ist da, wo du tatsächlich Entscheidungen triffst. Brauchst du wirklich diesen S3-Tier, oder würde S1 deine Last bewältigen? Steht diese Always-on-Compute-Instanz am Wochenende untätig herum? Könntest du Spot-Instanzen für deine Trainingsjobs verwenden?

Als .NET-Entwickler neigen wir dazu, uns auf den Code zu konzentrieren und die Infrastrukturentscheidungen dem „Ops-Team" zu überlassen. Aber wenn du auf Azure deployst, sind diese Entscheidungen auch deine Entscheidungen.

Was wirklich funktioniert

Basierend auf dem Artikel und meiner eigenen Erfahrung — das macht den Unterschied:

Wisse, was du ausgibst und wofür. Tagge deine Ressourcen. Im Ernst. Wenn du nicht erkennen kannst, welches Projekt oder Experiment dein Budget auffrisst, kannst du nichts optimieren. Azure Cost Management mit ordentlichem Tagging ist dein bester Freund.

Setze Leitplanken, bevor du experimentierst. Nutze Azure Policy, um teure SKUs in Dev/Test-Umgebungen einzuschränken. Setze Ausgabenlimits für deine Azure-OpenAI-Deployments. Warte nicht, bis die Rechnung kommt, um festzustellen, dass jemand ein GPU-Cluster über das Wochenende laufen gelassen hat.

Dimensioniere kontinuierlich richtig. Die VM, die du beim Prototyping ausgewählt hast? Die ist wahrscheinlich falsch für die Produktion. Azure Advisor gibt dir Empfehlungen — schau sie dir tatsächlich an. Überprüfe monatlich, nicht jährlich.

Denke an den Lebenszyklus. Entwicklungsressourcen sollten heruntergefahren werden. Testumgebungen müssen nicht 24/7 laufen. Nutze Auto-Shutdown-Richtlinien. Für KI-Workloads im Speziellen solltest du Serverless-Optionen in Betracht ziehen, bei denen du pro Ausführung zahlst, statt Compute warmzuhalten.

Miss den Wert, nicht nur die Kosten. Das vergisst man leicht. Ein Modell, das mehr kostet, aber deutlich bessere Ergebnisse liefert, könnte die richtige Wahl sein. Das Ziel ist nicht, am wenigsten auszugeben — sondern klug auszugeben.

Das Fazit

Cloud-Kostenoptimierung ist kein einmaliges Aufräumen. Es ist eine Gewohnheit. Und da KI-Workloads die Ausgaben unvorhersehbarer machen als je zuvor, erspart dir der frühe Aufbau dieser Gewohnheit schmerzhafte Überraschungen später.

Wenn du ein .NET-Entwickler bist, der auf Azure baut, fang an, deine Cloud-Rechnung wie deinen Code zu behandeln — überprüfe sie regelmäßig, refaktoriere, wenn es unordentlich wird, und deploye nie, ohne zu verstehen, was es dich kosten wird.