Last Week in Azure & Tech – Vol. 11

Top-Thema der Woche: GPT-5.5 in Microsoft Foundry – OpenAIs Frontier-Modell wird Enterprise-ready

OpenAIs GPT-5.5 ist seit dem 24. April in Microsoft Foundry allgemein verfügbar – und markiert einen qualitativen Sprung bei agentic AI im Enterprise-Kontext. Das Modell bringt tiefere Long-Context-Reasoning-Fähigkeiten, zuverlässigere agentic Execution, verbesserte Computer-Use-Genauigkeit und höhere Token-Effizienz – optimiert für anspruchsvolle professionelle Workflows in Software Engineering, Legal und Health Sciences.

Die wichtigsten Neuerungen:

• Frontier Intelligence im Enterprise-Rahmen: GPT-5.5 liefert die nächste Stufe bei Reasoning und Tool-Use, eingebettet in Foundrys Governance-, Monitoring- und Compliance-Framework. Anders als beim direkten Azure OpenAI Service bietet Foundry zusätzliche Enterprise Controls
• 1M Context Window: Für Entwickler über die API verfügbar – relevant für komplexe Dokumentenanalyse, Code-Reviews ganzer Repositories und Multi-Step-Agent-Workflows
• Agentic Execution verbessert: Zuverlässigere Ausführung mehrstufiger Aufgaben mit weniger Halluzinationen und besserer Tool-Orchestrierung
• Parallel: Agent Framework v1.0 GA und Hosted Agents: Microsoft liefert zeitgleich das komplette Agent-Ökosystem – vom Framework über sichere Compute-Sandboxes bis zu wiederverwendbaren Toolboxes (siehe KI & Azure AI)

Meine Einschätzung: GPT-5.5 in Foundry ist nicht einfach „ein neues Modell“ – es ist der Moment, in dem agentic AI im Enterprise produktionsreif wird. Die Kombination aus GPT-5.5 als Reasoning Engine, Agent Framework v1.0 als Orchestrierungsschicht und Hosted Agents als sicherer Compute-Infrastruktur bildet einen vollständigen Stack. IT-Leiter sollten jetzt evaluieren, welche internen Prozesse von autonomen Agenten profitieren – aber mit klarem Governance-Framework starten. Die Toolbox-Funktion in Foundry erlaubt dabei, einmal konfigurierte Tools teamübergreifend wiederzuverwenden, statt sie pro Agent neu zu verdrahten.

🔗 GPT-5.5 in Microsoft Foundry 🔗 Agent Framework v1.0 GA

🤖 KI & Azure AI

Microsoft Agent Framework v1.0 GA – Vom Experiment zur Produktion

Das Microsoft Agent Framework erreicht v1.0 und damit Produktionsreife. Das Framework vereint die Foundations von Semantic Kernel und AutoGen in einer stabilen Agent-Abstraktion für .NET und Python. Mitgeliefert: First-Party-Connectors für Microsoft Foundry, Azure OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini und Ollama. Dazu kommen Hosted Agents in Foundry Agent Service – VM-isolierte Sandboxes mit persistentem Filesystem, in denen Agenten sicher Code ausführen können. Billing startet am 22. April ($0.0994/vCPU-Stunde). Toolboxes (Public Preview) ermöglichen die zentrale Kuration und Wiederverwendung von Tools über MCP, OpenAPI und A2A-Protokolle hinweg.

🔗 Agent Framework v1.0 🔗 Hosted Agents in Foundry 🔗 Toolboxes in Foundry

Kimi K2.6 in Microsoft Foundry – Open-Source-Alternative auf Frontier-Niveau

Moonshot AIs Kimi K2.6 ist ab sofort in Microsoft Foundry verfügbar – ein 1-Trillion-Parameter MoE-Modell mit 262K Context Window, Multi-Turn Tool Calling und Vision-Input. K2.6 erzielt 58.6 auf SWE-Bench Pro (GPT-5.4: 57.7, Claude Opus 4.6: 53.4) und skaliert Agent Swarms auf bis zu 300 parallele Sub-Agenten. Für Teams, die eine Open-Source-Alternative zu proprietären Frontier-Modellen evaluieren, ein ernstzunehmender Kandidat.

🔗 Kimi K2.6 in Foundry

MAI-Modelle – Microsofts eigene Sprach- und Bildmodelle

Microsoft veröffentlicht drei hauseigene KI-Modelle: MAI-Transcribe-1 (Speech-to-Text für 25 Sprachen, optimiert für verrauschte Enterprise-Szenarien wie Meetings und Call Center), MAI-Voice (Text-to-Speech) und MAI-Image. Diese Modelle ergänzen das Foundry-Portfolio um Microsofts eigene Modellentwicklung neben OpenAI-Modellen.

🔗 MAI-Modelle Blog

Microsoft Discovery – Agentic R&D at Scale

Microsoft stellt „Discovery“ vor – eine Plattform für agentic R&D, die KI-gestützte Forschung und Entwicklung in großem Maßstab ermöglicht. Zielgruppe sind Unternehmen, die KI nicht nur für einzelne Tasks, sondern für durchgängige Forschungs-Workflows einsetzen wollen.

🔗 Microsoft Discovery

📋 Azure Core Updates

🏢 Hybrid & Modern Work

Private Subnets by Default – Azure VNets werden Secure-by-Default

Eine der weitreichendsten Infrastruktur-Änderungen dieser Woche: Ab API-Version 2025-07-01 (aktiv seit 31. März 2026) erstellen neue VNets standardmäßig private Subnets. Das bedeutet: defaultOutboundAccess ist auf false gesetzt, Azure vergibt keine impliziten Outbound Public IPs mehr. Wer Outbound-Konnektivität braucht, muss explizit NAT Gateway, Load Balancer oder Public IP konfigurieren. Bestehende Workloads sind nicht betroffen, aber jede neue Infrastruktur muss diese Änderung berücksichtigen. Terraform- und Bicep-Templates prüfen!

🔗 Private Subnets by Default

Azure Monitor Pipeline GA – Telemetrie-Ingestion im Enterprise-Maßstab

Azure Monitor Pipeline ist jetzt allgemein verfügbar und löst eines der größten Observability-Probleme: skalierbare, sichere Telemetrie-Ingestion über Regionen, Clouds und On-Premises hinweg. Basierend auf OpenTelemetry bietet die Pipeline lokale Pufferung, automatisches Backfill bei Konnektivitätsproblemen und lokale Transformation (Filtern, Aggregieren, Reshaping) vor dem Senden an Azure Monitor. Besonders relevant: Die Pipeline ist ohne zusätzliche Kosten für Ingestion in Azure Monitor und Microsoft Sentinel nutzbar.

🔗 Azure Monitor Pipeline GA

Securing MCP – Control Plane für Agent Tool Execution

Microsoft veröffentlicht Guidance zur Absicherung von MCP (Model Context Protocol) in Agent-Architekturen. Der Blogpost beschreibt, wie Unternehmen eine Control Plane für Tool Execution aufbauen – relevant für alle, die MCP-basierte Agenten in Produktion bringen. Themen: Authentication, Authorization, Input Validation und Audit Logging für MCP-Tool-Aufrufe.

🔗 Securing MCP

🔐 Security & Identity

• Sentinel MCP Server mit Claude-Integration (GA): Microsoft Sentinel unterstützt jetzt offiziell Claude als externen KI-Assistenten über das MCP-Protokoll. Analysten können Security-Daten per natürlicher Sprache erkunden, Incidents zusammenfassen und Alerts untersuchen – mit Entra ID-basierter Authentifizierung und strikter Tenant-Isolation. Ein klares Signal, dass Microsoft Sentinel als offene Plattform für verschiedene AI-Backends positioniert
• Axios npm Supply Chain Compromise – Azure Pipelines Guidance: Am 31. März wurden schadhafte Axios-Versionen (1.14.1, 0.30.4) veröffentlicht – ein Supply-Chain-Angriff, den Microsoft Threat Intelligence dem nordkoreanischen Akteur Sapphire Sleet zuordnet. Azure DevOps-Kunden sollten sofort prüfen, ob kompromittierte Versionen in CI/CD-Pipelines installiert wurden. Betroffene Secrets rotieren, Artifacts aus kompromittierten Builds als nicht vertrauenswürdig behandeln
• Sentinel Support im Azure Portal verlängert: Microsoft verlängert den Sentinel-Support im Azure Portal bis 31. März 2027 (ursprünglich Juli 2026). Mehr Zeit für die Migration zum Defender Portal
• Zero Trust Networking für Azure OpenAI: Neues Architecture Pattern zur Absicherung von Azure OpenAI-Deployments mit Private Endpoints, NSGs und Azure Firewall – da Azure OpenAI standardmäßig öffentlich erreichbar ist
• AI Agents für Threat Intelligence: Microsoft zeigt, wie AI Agents Threat Intelligence automatisch in validierte Detections übersetzen – mit einem Benchmark-Framework zur Messung der Agent-Performance bei realen Security-Aufgaben

🔗 Sentinel MCP Server + Claude 🔗 Axios Supply Chain Guidance 🔗 Zero Trust for Azure OpenAI

⚠️ Abkündigungen & Retirements

ACHTUNG: Application Gateway V1 wird morgen (28. April) retired – wer noch V1-Instanzen hat, muss heute handeln. Dazu endet am 30. April der iOS 16-Support für Defender for Endpoint und die Teams Office 365 Connectors werden eingestellt. GPT-4.1 Family Modelle sind bereits im Retirement-Prozess – bestehende Deployments prüfen und auf neuere Modellversionen migrieren.

💰 FinOps-Tipp der Woche: Savings Plan for Databases – Flexible Einsparungen ohne Service-Lock-in

Microsoft hat den neuen Azure Savings Plan for Databases eingeführt – ein spend-basiertes Preismodell, das bis zu 35% Einsparungen gegenüber Pay-as-you-go für Datenbankdienste ermöglicht. Im Gegensatz zu Reserved Instances bindet man sich nicht an eine spezifische Datenbank-SKU, sondern committet sich auf einen stündlichen Dollar-Betrag.

Warum das relevant ist: Wer heute Azure SQL, Cosmos DB, PostgreSQL Flexible Server oder MySQL nutzt, zahlt oft Pay-as-you-go-Preise, weil Reserved Instances zu unflexibel sind. Der neue Savings Plan löst dieses Dilemma: Ein fixes stündliches Commitment wird automatisch auf die nutzungsstärksten Datenbank-Services angewendet – service-, regions- und SKU-übergreifend.

Konkrete Umsetzung:

bash

# Aktuelle Datenbank-Kosten der letzten 30 Tage analysieren
az cost management query \
  --type ActualCost \
  --timeframe MonthToDate \
  --dataset-filter "{\"dimensions\":{\"name\":\"ServiceFamily\",\"operator\":\"In\",\"values\":[\"Databases\"]}}" \
  -o table
# Personalisierte Savings Plan-Empfehlung abrufen
az advisor recommendation list \
  --filter "Category eq 'Cost'" \
  --query "[?contains(shortDescription.problem,'Savings')]" \
  -o table
# Savings Plan im Portal konfigurieren:
# Portal -> Cost Management -> Savings Plans -> Add
# Term: 1 Jahr, Hourly Commitment basierend auf Empfehlung
# Zahlung: Upfront (maximale Ersparnis) oder monatlich (kein Aufpreis)

Zusätzlich beachten: Der Savings Plan wendet Rabatte automatisch auf die Nutzung an, die die größten Einsparungen bringt – Priority-basiert über alle berechtigten Datenbank-Services. FinOps-Teams sollten die aktuelle Datenbank-Landschaft inventarisieren und den stündlichen Commitment-Betrag anhand der letzten 30 Tage Nutzung kalibrieren.

🔗 Savings Plan for Databases 🔗 Azure Savings Plans Overview

💡 Deep Dive: Private Subnets by Default – Was sich in Azure Networking fundamental ändert

Azure hat mit API-Version 2025-07-01 eine der grundlegendsten Änderungen am Networking-Stack vorgenommen: Neue Virtual Networks verwenden standardmäßig private Subnets. Was technisch harmlos klingt, hat weitreichende Auswirkungen auf Infrastruktur-as-Code, Deployment-Pipelines und die Art, wie Teams neue Workloads provisionieren.

Das Problem: Impliziter Outbound-Zugriff war ein Sicherheitsrisiko

Bis März 2026 erhielt jede VM in einem Azure VNet automatisch eine implizite Outbound Public IP – auch ohne explizite Konfiguration. Das war bequem, aber ein Sicherheitsproblem: Workloads konnten unkontrolliert ins Internet kommunizieren, ohne dass dies in NSG-Regeln, Firewall-Logs oder Compliance-Reports sichtbar war. Für Zero-Trust-Architekturen ein Widerspruch.

Was sich geändert hat:

Ab API-Version 2025-07-01 (aktiv seit 31. März 2026) gilt:

1. defaultOutboundAccess ist false: Neue Subnets haben keinen impliziten Internet-Zugang mehr
2. Keine impliziten Public IPs: Azure weist VMs keine versteckten Outbound-IPs mehr zu
3. Explizite Outbound-Methode erforderlich: NAT Gateway, Load Balancer mit Outbound Rules oder Instance-Level Public IP

Betroffene Szenarien:

NAT Gateway als empfohlene Lösung:

bash

# NAT Gateway erstellen
az network nat gateway create \
  --name natgw-prod \
  --resource-group rg-networking \
  --location westeurope \
  --sku Standard \
  --idle-timeout 10
# Public IP für NAT Gateway erstellen
az network public-ip create \
  --name pip-natgw-prod \
  --resource-group rg-networking \
  --location westeurope \
  --sku Standard \
  --allocation-method Static
# Public IP dem NAT Gateway zuweisen
az network nat gateway update \
  --name natgw-prod \
  --resource-group rg-networking \
  --public-ip-addresses pip-natgw-prod
# NAT Gateway einem Subnet zuweisen
az network vnet subnet update \
  --name snet-workloads \
  --vnet-name vnet-prod \
  --resource-group rg-networking \
  --nat-gateway natgw-prod

Bicep-Anpassung (vorher/nachher):

bicep

// VORHER: Funktionierte implizit - keine Outbound-Konfiguration nötig
resource vnet 'Microsoft.Network/virtualNetworks@2024-01-01' = {
  name: 'vnet-prod'
  location: location
  properties: {
    addressSpace: { addressPrefixes: ['10.0.0.0/16'] }
    subnets: [{ name: 'snet-workloads', properties: { addressPrefix: '10.0.1.0/24' } }]
  }
}
// NACHHER: NAT Gateway explizit konfigurieren
resource natGateway 'Microsoft.Network/natGateways@2025-07-01' = {
  name: 'natgw-prod'
  location: location
  sku: { name: 'Standard' }
  properties: { idleTimeoutInMinutes: 10 }
}
resource vnet 'Microsoft.Network/virtualNetworks@2025-07-01' = {
  name: 'vnet-prod'
  location: location
  properties: {
    addressSpace: { addressPrefixes: ['10.0.0.0/16'] }
    subnets: [{
      name: 'snet-workloads'
      properties: {
        addressPrefix: '10.0.1.0/24'
        defaultOutboundAccess: false
        natGateway: { id: natGateway.id }
      }
    }]
  }
}

Einschränkungen und Stolperfallen:

• NAT Gateway kostet ca. $32/Monat (Basis) plus $0.045/GB Datenverarbeitung – bei 100 Subnets kein Trivial-Betrag
• NAT Gateway ist Subnet-scoped, nicht VNet-scoped – jedes Subnet mit Outbound-Bedarf braucht eine Zuweisung
• Bestehende Workloads sind nicht betroffen – nur neue VNets/Subnets ab API 2025-07-01
• Azure Portal nutzt die neue API seit 1. April 2026 – Terraform und Bicep erst nach Provider-Update
• AKS-Cluster in neuen VNets: Node Pools brauchen explizit NAT Gateway für Image Pulls, wenn kein Private MCR konfiguriert ist

Meine Einschätzung: Diese Änderung ist überfällig und richtig. Impliziter Outbound-Zugriff war ein Relikt aus der Frühzeit von Azure und ein ständiges Compliance-Risiko. Für bestehende Infrastruktur ändert sich nichts, aber alle IaC-Templates, Landing Zones und Deployment-Pipelines müssen aktualisiert werden. Wer Azure Landing Zones mit dem ALZ Accelerator nutzt, sollte prüfen, ob die neueste Version bereits private Subnets unterstützt. Alle anderen: NAT Gateway als Standard in eure Netzwerk-Blueprints aufnehmen.

🔗 Private Subnets by Default 🔗 NAT Gateway Dokumentation 🔗 Default Outbound Access

✅ Eine Maßnahme für diese Woche

IaC-Templates auf Private Subnets aktualisieren und Axios-Versionen in Pipelines prüfen

bash

# 1. DRINGEND: Application Gateway V1 - letzte Chance (Retirement morgen!)
az network application-gateway list \
  --query "[?sku.tier=='Standard' || sku.tier=='WAF'].{Name:name, RG:resourceGroup, Tier:sku.tier}" \
  -o table
# 2. Axios Supply Chain Check - kompromittierte Versionen in Pipelines identifizieren
# In euren Repos nach betroffenen Versionen suchen:
# grep -r '"axios": "1.14.1"\|"axios": "0.30.4"' --include="package-lock.json"
# Betroffene Versionen: 1.14.1 und 0.30.4 -> Rollback auf 1.14.0 / 0.30.3
# 3. IaC-Templates prüfen: Nutzen eure Bicep/Terraform-Templates noch
# impliziten Outbound-Zugriff? NAT Gateway als Standard aufnehmen
az network nat gateway list \
  --query "[].{Name:name, RG:resourceGroup, Subnets:subnets[].id}" \
  -o table
# 4. Savings Plan for Databases evaluieren - aktuelle DB-Kosten prüfen
az cost management query \
  --type ActualCost \
  --timeframe MonthToDate \
  --dataset-filter "{\"dimensions\":{\"name\":\"ServiceFamily\",\"operator\":\"In\",\"values\":[\"Databases\"]}}" \
  -o table

Die Application Gateway V1 Migration hat absolute Priorität – morgen ist Deadline. Parallel: Alle JavaScript/TypeScript-Projekte auf kompromittierte Axios-Versionen prüfen und betroffene Secrets rotieren. Mittelfristig: IaC-Templates und Landing Zones auf Private Subnets by Default vorbereiten.

🔗 Application Gateway V1 Migration 🔗 Axios Mitigation Guide