ITOps Talk Blog articles

Azure Files, Reimagined: Top-Level Shares with Per-Share Networking, Billing, and Scale

Pierre_Roman — Thu, 23 Jul 2026 07:00:00 GMT

Hello Folks!

If you have ever wrestled with Azure Files inside a storage account, juggling shared RBAC, shared networking, and shared IOPS across a pile of shares that really should not live together, this session is going to address all that. During Microsoft Azure Infra Summit 2026, Vincent Du and Will Gries (both Product Managers on the Azure Files team) walked us through the new Microsoft.FileShares resource provider, a management model that promotes the file share itself to a top-level Azure resource.

📺 Watch the session:

Why IT Pros Should Care

For years, file shares lived inside a storage account, and that storage account dictated a lot of decisions for you. If one team needed a private endpoint and another needed a service endpoint, you either compromised or you created another storage account. If one share got hot and consumed all the IOPS, the other shares felt it too. Vincent and Will are on the team that built the new model to remove that compromise.

Here is what changes for you as an IT pro:

Each file share is its own Azure resource with its own RBAC, networking, billing, IOPS, and throughput.
Per-share cost shows up directly in Azure Cost Management’s per-resource view, no more Excel guesswork.
Encryption in transit is on by default for NFS shares, at no extra cost.
Provisioning is dramatically faster. In their head-to-head demo, 200 shares finished in about 50 seconds on the new model versus about 720 seconds with the classic flow.
A new MCP server lets you create and manage shares from GitHub Copilot in VS Code with natural language.

In short, the new model trades the storage-account-as-gatekeeper pattern for something that feels a lot more like the rest of Azure (think VMs and disks, where the resource you care about is the resource you actually manage).

What Microsoft.FileShares Does, a Technical Overview

The new Microsoft.FileShares resource provider lets you deploy a file share without first standing up a storage account. When you go into the Azure portal, search for “File share,” and click create, you fill out a single create blade with the things that actually matter for that share: name, region, redundancy (LRS or ZRS), provisioned capacity, IOPS and throughput, networking, and tags. Microsoft Learn confirms the provisioned capacity range is 32 GiB to 262,144 GiB, and only LRS and ZRS redundancy are available at launch (see the Create a file share doc linked below).

At GA, the new experience supports NFS 4.1 on the SSD media tier. SMB support, HDD support, customer-managed key encryption at rest, soft delete, and the AKS CSI driver integration are all on the roadmap and called out as the most-requested follow-ups. If you need those features today, the classic file share inside a storage account is still there for you.

In the portal, Vincent showed off a small but meaningful detail: the icon color changed from blue (classic) to purple (new). It is a small thing, but when you are scanning a resource group, that visual cue saves you a click.

How It Works Under the Hood

The new model is built on the provisioned v2 billing structure. Microsoft Learn describes provisioned v2 as a billing model where you independently provision storage, IOPS, and throughput, and you pay for what you provision regardless of how much you actually use. This is a real shift from the older provisioned v1 model, where IOPS and throughput were a function of how much storage you provisioned.

Will walked through the math. In his example, provisioning 14 TiB of storage on v1 gave 17,000 IOPS, about 1.5 GB/s throughput, and a bill of roughly $2,297. Moving to v2 with the exact same numbers was already noticeably cheaper. Then, because v2 lets you tune storage, IOPS, and throughput separately, he provisioned the exact storage he needed with slightly less IOPS and throughput, dropping the bill to roughly a third. For database-hot workloads you can dial IOPS up; for hot archive scenarios you can dial them down to the minimum. That kind of flexibility is genuinely useful.

Encryption in transit deserves its own callout. The new shares default to encrypted NFS mounts using the AZNFS mount helper. Microsoft Learn explains that AZNFS wraps the NFS connection in a Stunnel-based TLS tunnel using AES-GCM, so you get TLS protection without needing Kerberos or external authentication. The helper installs cleanly on Ubuntu, RHEL, SUSE, Rocky, Oracle Linux, Alma Linux, and Azure Linux. If a workload genuinely cannot use the encrypted mount, you can uncheck the box and fall back to a traditional NFS mount.

Networking is per share. You can attach a service endpoint or a private endpoint to each individual share, which means you can put a strict private-endpoint-only share next to a service-endpoint share for dev/test, all in the same resource group, without compromise.

On the request side, classic shares throttle with a fixed window (you can burst, then you are locked out for the rest of the window). The new model uses a token-bucket algorithm (the same one Azure Resource Manager itself uses), which means you get a sustained refill rate. The team also gave you a separate delete bucket, so a big cleanup operation does not starve writes. That detail matters more than it sounds: batch cleanups against the classic model regularly crowd out new share creation.

Real-World Value

Where does this actually pay off? A few honest scenarios:

Mission-critical and regulated workloads. A healthcare org with workloads at different sensitivity levels can put strict private-endpoint-only shares next to less sensitive service-endpoint shares without the storage-account ceiling.
Chargeback and showback. With per-share resources, finance can pull a cost report that lines up to the team or project that owns each share. No more saying “we cannot itemize, the storage account is shared.”
High-density tenants. The classic model effectively caps you at 34 file shares on an SSD provisioned v2 storage account (because of IOPS minimums) and 50 absolute. The new model goes up to 10,000 shares per subscription per region. That is a different game.
Tuned database and analytics shares. Provisioned v2 lets you right-size IOPS to the workload. As Will showed, that can drop the bill to roughly a third for the right shape of workload.
Faster deployment automation. A 14x improvement on a 200-share deployment is not a micro-optimization. If you spin up environments for CI, training, or per-customer tenants, that adds up quickly.

The honest tradeoff: today, the new model is NFS-only on SSD. If you need SMB, HDD, customer-managed keys for NFS, or AKS CSI driver support, stay on the classic model for now. The team was upfront about that, and the GA-and-then-iterate roadmap is clear.

Getting Started

Here is the concrete path:

Register the Microsoft.FileShares and Microsoft.Storage resource providers on your subscription (Subscriptions, Resource providers, Register).
From the Azure portal, search for “File share” in the marketplace and click Create. Pick LRS or ZRS, set the capacity between 32 GiB and 262 TiB, and either accept the recommended IOPS/throughput or set them manually.
On the Advanced tab, leave “Require encryption in transit” enabled (it is on by default) and pick a custom mount name if you want one distinct from the resource name.
On the Networking tab, attach a service endpoint or a private endpoint, per share.
Mount it on your Linux VM with the AZNFS mount helper. The portal generates the exact command for your distribution.
If you live in IaC land, the Microsoft.FileShares ARM and Bicep types are available, and Terraform support is coming.
If you live in AI-assisted dev land, install the Azure MCP server and ask Copilot in VS Code to create a share for you, pointing at an existing VNet.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here.

Cheers!

Pierre Roman

Some tools and techniques for hardening Windows Server

OrinThomas — Wed, 22 Jul 2026 20:30:09 GMT

In this post I go over some tools and techniques exist for hardening Windows Server. As always, apply controls according to the server's role, test them against representative workloads before production rollout, document approved exceptions, and maintain tested console and recovery access in case a security control affects management or application compatibility.

Apply the role-specific Windows Server 2025 baseline with OSConfig

Security baselines turn hundreds of individual security decisions into a consistent, role-aware desired state. Using OSConfig reduces exposure caused by insecure defaults, legacy protocols, inconsistent administrator choices, and configuration drift that attackers can exploit for credential theft, lateral movement, or persistence.

You can use use OSConfig at build time to apply the Microsoft security baseline that matches the server role: SecurityBaseline/WindowsServer/2025/MemberServer, SecurityBaseline/WindowsServer/2025/DomainController, or SecurityBaseline/WindowsServer/2025/WorkgroupMember. The baseline contains more than 300 settings covering network exposure, credentials, lateral movement, persistence resistance, and auditing. It can be managed through PowerShell, Windows Admin Center, or Azure Policy for Azure Arc-enabled servers.

You can keep OSConfig drift control enabled so unauthorized or accidental changes are detected and corrected. Pilot the baseline with each workload, record required exceptions, and manage those exceptions centrally rather than weakening the baseline broadly.

Implementation steps: Identify the server's role and the management authority that will own its settings, install the OSConfig PowerShell module, review the matching scenario, and apply it first to a representative test server. Validate application and management access, deploy the scenario in controlled rings, schedule and complete the restart required after applying the baseline, verify the desired configuration and compliance results, enable drift control, and record any approved exceptions and recovery procedures.

Possible drawbacks: A baseline can disrupt legacy applications, authentication methods, network flows, or management tools that depend on weaker settings. Drift control can also reverse intentional emergency changes if they aren't recorded through the correct authority, so staged testing, documented exceptions, and tested recovery access are essential.

Documentation on Learn: OSConfig security configuration for Windows Server | Deploy Windows Server 2025 security baselines with OSConfig | OSConfig security settings repository

Use Secured-core hardware and enable platform security

Windows Server secured-core combines hardware, firmware, virtualization, and operating-system protections to establish trust before Windows starts and preserve that trust while it runs. These controls mitigate bootkits, malicious or vulnerable kernel drivers, direct memory access attacks, firmware tampering, and attempts to extract credentials from the operating system.

You deploy on hardware or virtual machines that support TPM 2.0, UEFI Secure Boot, virtualization-based security, DMA protection, and the other Secured-core requirements. Enable the OSConfig SecuredCore scenario and verify that Credential Guard, hypervisor-protected code integrity, kernel protections, and the signed boot chain are active.

You need to keep system firmware, TPM firmware, hypervisor components, and hardware drivers current. Test older drivers before enabling enforcement because incompatible kernel drivers can prevent security features from activating or can affect boot reliability.

Implementation steps: Confirm that the physical server or virtual-machine platform meets the Secured-core requirements, update firmware and drivers, and enable TPM 2.0, Secure Boot, virtualization extensions, and DMA or IOMMU protection in the platform configuration. Apply the OSConfig SecuredCore scenario or configure the features through Windows Admin Center, restart as required, verify that each protection is active, record evidence of the hardware capabilities and running Windows protections rather than only the assigned policy, and monitor for driver or workload compatibility issues.

Possible drawbacks: Secured-core features require compatible hardware, firmware, hypervisors, and signed drivers, which can increase procurement costs or rule out older systems. Virtualization-based protections can introduce a workload-dependent performance impact, and incompatible drivers or firmware can cause application failures, feature activation problems, or difficult boot recovery.

Documentation: What is Secured-core server? | Configure Secured-core server | Windows Server 2025 secured-core hardware requirements

Deploy Server Core and minimize installed components

Attack-surface reduction removes code, services, interfaces, and utilities that an attacker could exploit or misuse after gaining access. A minimal Server Core deployment lowers the number of vulnerabilities that require patching and reduces opportunities for interactive attacks, malicious browsing, persistence, and abuse of unnecessary administrative tools.

Install Server Core unless a supported workload specifically requires Desktop Experience. Server Core has a smaller local interface and component footprint, reducing exposed code, maintenance requirements, and opportunities for interactive misuse. Windows Server 2025 can't convert between Server Core and Server with Desktop Experience after installation, so changing this choice later requires a clean installation.

Install only the roles, features, management agents, and application components required for the server's purpose. Remove obsolete utilities and unused software, avoid browsing the web from servers, and disable unnecessary services only after confirming role and application dependencies. Where practical, dedicate each server to a single security or workload role.

Implementation steps: Confirm that the workload and vendor support Server Core, formally record the installation-option decision before deployment, select Server Core during installation, and define the minimum roles, features, agents, and software required for the server's purpose. Install only those components, configure remote management and recovery access, remove or disable unused components after dependency testing, and verify that the application, monitoring, backup, patching, and support processes still function.

Possible drawbacks: Server Core can make local troubleshooting less familiar and increases reliance on remote management, automation, and command-line skills. Some vendor applications, support tools, or administrators require Desktop Experience, and removing roles or disabling services without dependency testing can break workloads, monitoring, backup, or recovery operations.

Documentation: What is the Server Core installation option? | Server Core and Desktop Experience installation options

Ensure rapid patching and continuous vulnerability management

Patching and vulnerability management identify and close known weaknesses before attackers can reliably exploit them. This practice reduces exposure to remote-code execution, privilege escalation, ransomware, vulnerable drivers, compromised third-party components, and attacks that target publicly documented vulnerabilities soon after disclosure. Make sure you are aware if any of your server workloads have not got the latest security updates deployed

Maintain an inventory of operating-system, application, driver, firmware, and management-agent versions. Use deployment rings to test updates quickly, meet defined remediation deadlines, install out-of-band security updates when required, and monitor update compliance and pending restarts. Azure Update Manager can provide centralized assessment and orchestration for Azure and Azure Arc-enabled servers.

Use Microsoft Defender Vulnerability Management or an equivalent platform to discover exposures, prioritize remediation by exploitability and business impact, and verify that fixes actually remove the vulnerability. Patching Windows while leaving internet-facing applications, drivers, or firmware obsolete does not adequately harden the server.

Implementation steps: Inventory servers and every supported update source, define remediation deadlines and deployment rings, and configure Azure Update Manager or another actively developed orchestration platform. Windows Server Update Services remains supported and available but is deprecated and should be treated as a legacy option rather than the preferred platform for a new long-term design. Run vulnerability assessments, prioritize exposed and actively exploited weaknesses, test updates, deploy them with coordinated reboots, verify compliance after installation, and maintain rollback and exception procedures.

Possible drawbacks: Updates can require reboots, consume maintenance windows, or introduce application, driver, and performance regressions. Vulnerability scanners and management agents also consume resources and can generate false positives, so organizations need test rings, rollback procedures, maintenance coordination, and a risk-based process for temporary deferrals.

Documentation: Azure Update Manager overview | Cloud-native patch management for Azure Arc-enabled servers | Microsoft Defender Vulnerability Management | Deprecated Windows Server features

Implement Microsoft Defender Antivirus and endpoint detection and response

Antivirus and endpoint detection and response combine prevention with behavioral monitoring and investigation. They mitigate malicious files, ransomware, web and network-delivered payloads, suspicious process activity, persistence mechanisms, credential theft, and attacks that evade simple signature-based detection.

Run Microsoft Defender Antivirus in active mode unless a documented and tested security architecture requires another antimalware product. Enable real-time protection, behavior monitoring, cloud-delivered protection, automatic sample submission, and frequent security-intelligence updates. Use the OSConfig Defender/Antivirus/WindowsServer/2025 scenario as the recommended Server 2025 configuration starting point.

Onboard servers to Microsoft Defender for Endpoint or Microsoft Defender for Servers for endpoint detection and response, investigation, and centralized visibility. Enable tamper protection and keep exclusions narrow, workload-specific, and regularly reviewed; broad path, process, or extension exclusions create useful hiding places for attackers.

Implementation steps: Confirm licensing, connectivity, proxy, and third-party antivirus requirements, then apply the OSConfig Defender Antivirus scenario or an equivalent centrally managed policy. Enable real-time, behavior, cloud-delivered, sample-submission, and tamper protections; onboard the server to Defender for Endpoint or Defender for Servers; review Microsoft's built-in, automatic server-role, and workload-specific exclusions before adding any manual exclusion; verify sensor health, signature currency, alert delivery, and investigation access; and periodically confirm that every manual exclusion remains necessary.

Possible drawbacks: Real-time scanning and endpoint telemetry can add CPU, memory, disk I/O, network, and licensing costs, particularly on high-throughput workloads. False positives or quarantine actions can interrupt services, while cloud-delivered capabilities can raise connectivity, privacy, or data-residency considerations; performance exclusions must therefore be tested and kept narrowly scoped.

Documentation: Microsoft Defender Antivirus in Windows | Microsoft Defender for Endpoint on Windows | Defender Antivirus exclusions | Protect against security-setting tampering

Deploy attack surface reduction and network protection on your Windows Server workloads

Attack surface reduction rules prevent high-risk behaviors rather than waiting for a specific malicious file to be identified, while network protection blocks access to known or suspicious destinations. Together they mitigate ransomware, credential theft, malicious scripts, abuse of trusted tools, vulnerable drivers, command-and-control traffic, and payload delivery.

Configure Microsoft Defender attack surface reduction rules to block common behaviors used by ransomware, credential theft, malicious scripts, vulnerable signed drivers, and executable content. Begin with audit or warning mode, review telemetry for legitimate workload dependencies, create narrowly scoped exclusions, and then move suitable rules to block mode on a defined schedule.

Enable network protection where supported to prevent processes from reaching malicious or untrusted destinations. Manage these controls centrally through Group Policy, Microsoft Defender for Endpoint security settings management, or another supported policy platform.

Implementation steps: Inventory server workloads and make a rule-by-rule applicability decision for each server role rather than reusing a generic workstation ASR profile unchanged. Create a centrally managed ASR and network-protection policy that initially uses audit or warning mode, collect and review events, confirm business-critical dependencies, create narrowly scoped exclusions, move applicable rules to block mode through deployment rings, verify that protected applications remain functional, and continuously review detections and exception use.

Possible drawbacks: ASR rules can block legitimate automation, administrative tools, installers, scripts, or line-of-business applications that exhibit high-risk behavior. Audit mode can produce substantial telemetry, and broad exclusions can undermine the protection, so successful deployment requires workload testing, event review, careful exception design, and ongoing tuning.

Documentation: Attack surface reduction capabilities | Evaluate Microsoft Defender Antivirus and ASR rules using Group Policy

Allow only trusted code with App Control for Business

Application control changes the execution model from allowing everything except known malware to allowing only code that satisfies an approved policy. This technique mitigates unknown malware, ransomware, unauthorized administrative utilities, malicious scripts, unapproved drivers, and opportunistic payloads that antivirus has not yet classified.

Use App Control for Business to define which executables, scripts, installers, libraries, and drivers may run. Windows Server 2025 includes OSConfig scenarios for Microsoft's default policy and application blocklist. Start in audit mode, collect Code Integrity event ID 3076, create required supplemental allow policies, and move to enforcement only after representative workload testing. There are some good GUI tools written by MVPs published on GitHub that make this very easy. https://github.com/HotCakeX/Harden-Windows-Security

Monitor blocked-code event ID 3077 after enforcement and maintain a controlled process for policy updates and emergency recovery. Application allowlisting is substantially stronger than relying only on malware signatures because unapproved code is prevented from running even when it has not yet been classified as malicious.

Implementation steps: Verify that the device is running a production-signed Windows Server 2025 build because the OSConfig default policy doesn't permit flight-signed binaries. Inventory approved applications, scripts, drivers, publishers, and update mechanisms, then deploy the default policy and application blocklist through OSConfig in audit mode. Collect event ID 3076, build and deploy required supplemental policies, and sign policies only when the additional tamper resistance is required and certificate lifecycle, policy servicing, removal, and offline recovery have been tested. Test application updates and recovery, move the policy to enforcement in stages, and monitor event ID 3077 and policy health after deployment.

Possible drawbacks: Poorly designed policies can block legitimate applications, updates, scripts, drivers, or boot-critical components and can cause a severe service outage. Maintaining allow policies creates operational overhead, especially for frequently changing software, and approved tools can still be abused, so audit-mode deployment, controlled updates, and offline recovery procedures are necessary. Signed policies provide stronger tamper resistance but are intentionally harder to remove, including during recovery.

Documentation: Configure App Control for Business by using OSConfig | App Control for Business

Keep Windows Defender Firewall enabled with restrictive rules

A host firewall limits which systems and applications can communicate with the server, even when upstream network controls are absent or bypassed. Restrictive rules reduce exposure to service exploitation, scanning, lateral movement, remote administration abuse, command-and-control traffic, and accidental publication of listening services.

Enable Windows Defender Firewall on Domain, Private, and Public profiles. Retain the default block for unsolicited inbound traffic and create only the rules required by the server role. Scope rules by program or service, protocol, local port, remote address, interface, and profile rather than creating broad port-based or any-source exceptions.

Log dropped packets and successful connections where operationally appropriate, centrally monitor policy changes, and review stale rules. Apply explicit outbound restrictions to high-value or tightly controlled servers where feasible, especially when they should communicate with only a small set of update, identity, management, and application endpoints.

Implementation steps: Inventory listening services and required inbound and outbound flows, enable the firewall on all profiles, and create narrowly scoped rules for the server role. Decide whether locally created rules may merge with centrally deployed rules for each profile, verify the effective policy on representative servers, remove obsolete or duplicate rules, test application, domain, cluster, backup, and management traffic, enable appropriate logging, deploy the policy centrally, and monitor rule changes and blocked connections before introducing selective outbound restrictions.

Possible drawbacks: Incorrect firewall rules can interrupt application traffic, clustering, domain operations, monitoring, backup, or remote management and can make diagnosis difficult. Detailed connection logging consumes storage, while restrictive outbound policies require continuous maintenance as service endpoints change, so rules should be documented, tested, and deployed with recovery access.

Documentation: Windows Firewall rule recommendations | OSConfig baseline network protections

Harden Remote Desktop and remote administration

Remote administration exposes privileged authentication and interactive control paths that are attractive targets for brute-force attacks, credential theft, session hijacking, and exploitation of internet-facing services. Gateways, multifactor authentication, encrypted sessions, restricted source networks, and credential isolation reduce the likelihood that a stolen password or exposed management port leads directly to server compromise.

Disable Remote Desktop Services when it is not required. When it is required, use a VPN or Remote Desktop Gateway, require multifactor authentication and Network Level Authentication, restrict source networks and authorized groups, use trusted TLS certificates, and configure sensible idle and disconnected-session limits. Disable clipboard, drive, printer, port, and device redirection unless the operational need outweighs the data-transfer risk.

Use Remote Credential Guard only for compatible direct RDP administration of Active Directory-joined targets using Kerberos so credentials aren't sent to the remote host. Remote Credential Guard isn't supported through Remote Desktop Gateway or Remote Desktop Connection Broker. For helpdesk access to a potentially compromised host, use Restricted Admin mode instead of Remote Credential Guard. Never expose TCP port 3389 directly to the internet, and avoid using saved privileged credentials on ordinary administrator workstations.

Implementation steps: Disable RDP on servers that don't require it. For brokered or externally initiated access, place RDP behind a VPN or MFA-protected Remote Desktop Gateway and restrict permitted users and source networks. For compatible direct RDP administration of Active Directory-joined targets, configure Remote Credential Guard separately; use Restricted Admin mode for appropriate helpdesk scenarios. Configure Network Level Authentication, trusted TLS certificates, session limits, and required redirection controls, test routine and emergency access, and monitor remote logons and gateway activity.

Possible drawbacks: Gateways, VPNs, MFA services, and secure administrative hosts add licensing, infrastructure, and support dependencies, and their outage can block legitimate administration. Device-redirection restrictions can hinder support workflows, while Network Level Authentication and Remote Credential Guard have compatibility and delegation limitations; a separately secured emergency access path is therefore required.

Documentation: Plan multifactor authentication for Remote Desktop Services | Remote Credential Guard

Enforce least privilege and separate administrative identities

Least privilege limits each identity and session to the minimum actions required for its task. Separating standard and privileged accounts constrains the damage caused by phishing, token or password theft, malicious insiders, vulnerable administrative tools, and compromised lower-trust devices, while reducing opportunities for privilege escalation and persistence.

Give administrators standard user accounts for routine work and separate privileged accounts for administrative duties. Minimize membership of local Administrators, Domain Admins, Enterprise Admins, and other powerful groups; review membership and assigned user rights regularly; and prevent highly privileged identities from signing in to lower-trust servers and workstations.

Use Just Enough Administration endpoints, Windows Admin Center role-based access control, and time-limited elevation where possible. Delegate specific tasks rather than granting unrestricted interactive or PowerShell access, and maintain separately protected emergency accounts for identity-service outages.

Implementation steps: Inventory privileged human accounts, service principals, managed identities, service and automation credentials, scheduled tasks, local group membership, duties, and logon locations. Create separate standard and administrative identities, remove unnecessary standing memberships, delegate tasks through role groups, JEA endpoints, Windows Admin Center RBAC, or time-limited elevation, restrict high-tier logons to secured administrative hosts, test that each role can perform its approved duties, and monitor privileged-group, role, automation, and emergency-account use.

Possible drawbacks: Designing roles, JEA endpoints, approval processes, and time-limited access requires ongoing engineering and governance. Excessively narrow delegation can delay troubleshooting or incident response, while separate accounts add friction for administrators, so permissions should be tested against real duties and emergency access should remain tightly controlled but usable.

Documentation: Just Enough Administration | Windows Admin Center user access options | Enterprise access model

Deploy Windows LAPS for local administrator credentials

Windows LAPS replaces shared or manually maintained local administrator passwords with unique, random, automatically rotated credentials. It mitigates password reuse, pass-the-hash attacks, credential dumping, and broad lateral movement in which compromise of one server's local administrator credential grants access to many others.

Use Windows Local Administrator Password Solution to assign a unique, random, automatically rotated local administrator password to every server. The backup destination depends on join state: Active Directory-only devices can use only Active Directory, Microsoft Entra-only devices can use only Microsoft Entra ID, and hybrid-joined devices can use either destination but not both simultaneously. Tightly restrict and audit password retrieval, configure password history and post-authentication rotation, and monitor policy-processing failures.

Never reuse a common local administrator password across servers because one compromised password or hash can enable broad lateral movement. OSConfig provides the LAPS/WindowsServer/2025/MemberServer scenario for member servers. Workgroup systems can be managed through LAPS for Azure Arc, which Microsoft currently documents as a preview feature. On domain controllers, use Windows LAPS to manage the Directory Services Restore Mode password where appropriate.

Implementation steps: Select the password-backup destination permitted by the device's join state, prepare Active Directory or Microsoft Entra ID, and identify the local account to manage. For workgroup systems, evaluate the operational and support implications of the preview LAPS for Azure Arc service before adoption. Configure password length, complexity, age, history, and post-authentication actions through policy or OSConfig; configure DSRM password management for applicable domain controllers; delegate password read and reset permissions to a small approved group; pilot the policy; verify password backup and rotation; test authorized recovery; and monitor LAPS processing and retrieval events.

Possible drawbacks: LAPS introduces directory, policy, permissions, auditing, and recovery dependencies that must be designed correctly. Scripts or applications that rely on a fixed local password can fail, password rotation can disrupt active sessions or automation, and overly broad rights to retrieve stored passwords can create a new privileged credential repository for attackers to target.

Documentation: What is Windows LAPS? | OSConfig Windows LAPS scenario | LAPS for Azure Arc

Replace static service-account passwords with managed service accounts

Managed service accounts replace human-managed, long-lived service passwords with complex credentials that Active Directory changes automatically. This reduces exposure to password theft, reuse, weak password selection, expired credentials, secrets embedded in scripts, and persistence based on service accounts whose passwords are rarely rotated.

Use group managed service accounts for supported Windows services, scheduled tasks, and application pools in Active Directory environments. gMSAs provide automatic password management and reduce the need to store or manually rotate long-lived service credentials.

Windows Server 2025 also introduces delegated Managed Service Accounts for supported migrations from traditional service accounts. A dMSA binds authentication to approved machine identities, uses managed randomized keys, and disables use of the original service-account password. dMSA deployment requires a discoverable Windows Server 2025 domain controller, and an existing gMSA can't be migrated to a dMSA.

Grant each gMSA only the logon rights, resource permissions, and password-retrieval scope it requires. Do not make service accounts members of privileged groups unless unavoidable, prohibit interactive sign-in, remove obsolete accounts promptly, and monitor changes to the hosts permitted to retrieve each managed password.

Implementation steps: Inventory service identities and application dependencies, then select a gMSA for supported services that can directly use a managed account or evaluate a dMSA for a supported Windows Server 2025 migration from a traditional service account. For a gMSA, confirm Active Directory and key-distribution prerequisites, limit which hosts may retrieve its password, assign only required logon rights, permissions, and service principal names, install and test the account on approved hosts, migrate the service or task, and disable or remove the former static-password account. For a dMSA, confirm a discoverable Windows Server 2025 domain controller and follow the documented migration and rollback process.

Possible drawbacks: Managed service accounts depend on Active Directory and are not supported by every application, installer, or cross-platform workload. Migration can involve service-principal-name, delegation, permission, and clustering changes, while an overly broad password-retrieval scope allows additional hosts to use the identity. dMSA also requires Windows Server 2025 domain-controller availability and has migration rules that differ from gMSA, so compatibility, rollback, and access boundaries require careful testing.

Documentation: Secure group managed service accounts | Delegated Managed Service Accounts overview | Delegated Managed Service Accounts FAQ

Protect credentials and phase out legacy authentication

Credential isolation and modern authentication reduce the value of secrets that an attacker can extract or relay. Credential Guard, LSA protection, Kerberos AES, and retirement of weak authentication mitigate memory scraping, pass-the-hash, pass-the-ticket, NTLM relay, downgrade attacks, and cracking of obsolete password representations.

Verify that Credential Guard and Local Security Authority protection are active where hardware and workload compatibility permit. Windows Server 2025 enables Credential Guard by default on eligible domain-joined systems that aren't domain controllers, but the state should still be verified and centrally enforced where required. Use Negotiate with Kerberos and modern AES encryption for domain authentication, prevent storage of LM hashes or reversibly encrypted passwords, and keep delegated credentials non-exportable. NTLMv1 is removed in Windows Server 2025, and deprecated NTLMv2 should be treated only as a temporary compatibility fallback rather than an end state.

Audit NTLM and other legacy authentication dependencies before restricting or disabling them, then remove those dependencies in a controlled sequence. Do not disable legacy protocols blindly on production servers, but do not leave them enabled indefinitely solely because their consumers have not been inventoried.

Implementation steps: Confirm hardware and driver support, verify the default Credential Guard state, and use OSConfig or centrally managed policy to enforce Credential Guard and LSA protection where required. Enable NTLM auditing, inventory clients and services using legacy authentication, configure Negotiate and Kerberos AES, update affected service accounts, remediate dependencies, assign an owner and retirement date to every NTLMv2 exception, introduce NTLM restrictions in stages, and monitor authentication failures before broader enforcement.

Possible drawbacks: Virtualization-based credential protection requires compatible hardware and can have a workload-dependent performance or compatibility impact. Legacy devices, applications, trusts, or service configurations may still depend on NTLM or weaker cryptography, and disabling them without complete auditing can cause widespread authentication failures or outages.

Documentation: Credential Guard overview | OSConfig baseline credential protections | Deprecated Windows Server features

Harden SMB and file-server access

SMB hardening protects Windows file sharing and related management traffic against protocol downgrade, relay attacks, on-path tampering, brute-force authentication, guest access, data disclosure, and exploitation of obsolete implementations such as SMBv1. Signing verifies message integrity, while encryption protects sensitive content in transit.

Remove SMBv1, prevent insecure guest logons, retain and verify the Windows Server 2025 default requirement for inbound and outbound SMB signing, use SMB encryption for sensitive or untrusted network paths, and use SMB 3.x for modern file services. Treat any relaxation of signing for an incompatible third-party device as a documented, isolated, and time-bound exception. Windows Server 2025 also provides SMB authentication rate limiting and stronger signing and encryption capabilities that should be retained unless a documented compatibility requirement exists.

Restrict TCP port 445 to approved clients and servers, apply share and NTFS permissions according to least privilege, enable access-based enumeration where appropriate, and audit access to sensitive shares. Do not publish traditional SMB directly to the internet; use a supported secure access design such as SMB over QUIC when its requirements and threat model fit.

Implementation steps: Inventory SMB clients, servers, protocol versions, shares, and access requirements, then remove SMBv1 and insecure guest access. Verify that inbound and outbound signing remain required, document and isolate any temporary third-party compatibility exception, configure encryption, authentication rate limiting, and firewall scope according to the workload, review share and NTFS permissions, pilot changes with older clients and high-throughput workloads, and monitor SMB security, authentication, and performance events after enforcement.

Possible drawbacks: Mandatory SMB signing and encryption consume processor resources and can reduce throughput or increase latency on demanding file workloads. Older storage appliances, scanners, applications, or clients might not support modern SMB requirements, and overly restrictive port or permission changes can disrupt file access, administration, Group Policy, or backup operations.

Documentation: SMB security hardening | Secure SMB traffic in Windows Server

Require modern TLS and manage certificates securely

Modern TLS protects application and management traffic by authenticating endpoints and encrypting data in transit. Requiring current protocol versions, strong cipher suites, and trusted certificates mitigates eavesdropping, man-in-the-middle attacks, protocol downgrade, weak-cryptography attacks, and impersonation using invalid or compromised certificates.

Require TLS 1.2 or later and prefer TLS 1.3 where the application stack supports it. Windows Server 2025 disables TLS 1.0 and TLS 1.1 by default; verify that these protocols and obsolete SSL versions remain disabled and prevent unauthorized re-enablement. Disable weak cipher suites and obsolete hashes through a tested baseline rather than ad hoc registry changes. Inventory old agents, middleware, and network appliances first so incompatible dependencies can be upgraded instead of becoming permanent exceptions.

Use certificates from a trusted public or enterprise certification authority, protect private keys with restrictive access control, select appropriate key sizes and algorithms, monitor expiration, and automate renewal. After dependency review, remove expired, untrusted, orphaned, or unnecessary certificates from server stores.

Implementation steps: Inventory listening services, clients, protocol versions, cipher dependencies, and installed certificates, then replace weak or expiring certificates and confirm application support for modern TLS. Verify that TLS 1.0 and TLS 1.1 remain disabled, apply tested Schannel or OSConfig settings in stages, disable other legacy protocols and weak ciphers, validate every client and integration, rescan the endpoints, remove only certificates confirmed to be unnecessary, and implement automated certificate enrollment, renewal, expiration alerting, and private-key access review.

Possible drawbacks: Disabling old protocols and ciphers can break legacy clients, middleware, monitoring agents, or network devices with no modern TLS support. Certificate issuance, private-key protection, renewal automation, and revocation checking add operational complexity, and an expired or incorrectly deployed certificate can cause a complete service outage.

Documentation: TLS/SSL and Schannel overview | OSConfig baseline protocol protections | Deprecated Windows Server features

Encrypt operating-system and data volumes with BitLocker

BitLocker encrypts data at rest so possession of a disk or offline copy does not provide immediate access to its contents. It mitigates data theft from lost or stolen servers, removed drives, improperly decommissioned hardware, offline password-reset attacks, and attempts to read files by booting an alternate operating system.

Enable BitLocker on operating-system and data volumes, using TPM-backed protectors and additional startup authentication where the physical threat model and availability requirements justify it. Use virtual TPMs and supported host or cloud protections for virtual machines. Encryption protects data on removed drives, decommissioned hardware, stolen systems, and offline copies.

Escrow recovery information in a protected, recoverable directory or management service before enforcement. Limit access to recovery keys, audit retrieval, include key recovery in incident procedures, and test recovery on representative systems so encryption does not become an availability risk.

Implementation steps: Inventory operating-system and data volumes, confirm TPM or virtual TPM readiness, select protectors that meet the physical and availability threat model, and configure a protected recovery-key escrow location. Enable BitLocker in controlled stages, verify encryption and key backup, test normal reboot and recovery scenarios, document break-glass procedures, and continuously monitor encryption and protector compliance. Suspend protection for firmware or boot-chain maintenance only through an approved procedure, then verify that BitLocker protection resumes afterward.

Possible drawbacks: Lost recovery material can make encrypted data permanently inaccessible, while firmware, TPM, boot, or hardware changes can unexpectedly trigger recovery. Encryption can add some performance and operational overhead, and startup PINs can conflict with unattended reboot requirements, so protector selection, key escrow, and recovery testing must reflect the server's availability needs.

Documentation: BitLocker planning guide | BitLocker operations guide | BitLocker recovery overview

Configure detailed auditing and protect local logs

Detailed auditing records security-relevant activity so suspicious behavior can be detected, investigated, and attributed. Authentication, privilege, process, PowerShell, policy, and firewall logs help expose brute-force attempts, credential misuse, privilege escalation, persistence, defense evasion, and attacker efforts to alter system configuration.

Enable advanced audit policy for successful and failed logons, credential validation, account and group changes, sensitive privilege use, process creation with command-line capture, policy changes, removable storage, file shares, firewall activity, and other events relevant to the server role. The OSConfig baseline enables a broad audit configuration and increases important log sizes to improve forensic coverage.

Enable PowerShell module and script block logging, and use protected event logging where appropriate because command content can contain sensitive data. Increase log capacity and retention for the expected event volume, restrict permissions to clear or modify logs, monitor audit-policy changes, and synchronize time with trusted sources.

Implementation steps: Define the activities and events required for detection, investigation, and compliance, then apply advanced audit policy through OSConfig or Group Policy. Enable process command-line and PowerShell logging, measure event volume during a representative pilot, size and protect each log and forwarding path from the observed rates, configure trusted time synchronization, generate representative test events to confirm collection, and review event volume, retention, and policy health regularly.

Possible drawbacks: Detailed auditing can generate large volumes of events, consume storage and processing resources, and overwhelm analysts with noise if collection isn't tuned. Command-line and PowerShell logs can contain credentials or other sensitive data, while undersized logs may overwrite useful evidence, so access, retention, filtering, and capacity require deliberate design.

Documentation: OSConfig baseline auditing and visibility | Recommended audit policy for Windows Event Forwarding | PowerShell logging on Windows

Centralize security telemetry and alert on suspicious activity

Centralized telemetry moves evidence away from the system that generated it and correlates activity across servers, identities, and networks. This improves detection of distributed attacks, limits an intruder's ability to erase local evidence, and shortens response time for credential attacks, lateral movement, persistence, defense evasion, and destructive actions.

Forward security-relevant logs away from each server using Windows Event Forwarding, Azure Monitor, Microsoft Defender, a SIEM such as Microsoft Sentinel, or another protected collection platform. Include Security, System, Windows Defender, PowerShell, Code Integrity, Windows Firewall, Windows LAPS, and role-specific operational logs.

Create actionable alerts for repeated authentication failures, new or changed administrators, unexpected service or scheduled-task creation, security-control changes, Defender detections, App Control blocks, log clearing, unusual remote administration, and backup deletion. Restrict access to collectors and retention systems so an attacker who compromises a server cannot erase the centralized evidence.

Implementation steps: Select Windows Event Forwarding, Azure Monitor, Microsoft Defender, a SIEM, or a combination; define prioritized detection use cases and role-specific retention before selecting log channels and verbosity; design resilient collectors, access control, and capacity; and deploy the required agents or subscriptions. Onboard the prioritized channels, verify end-to-end ingestion and timestamps, create and test high-value detections and notifications, restrict access to the monitoring platform, and continuously monitor collection health and tune noisy rules.

Possible drawbacks: Central collection introduces bandwidth, storage, ingestion, licensing, retention, and analyst costs and can expose sensitive operational data if the monitoring platform is poorly secured. Collector failures create visibility gaps, while poorly tuned rules produce false positives and alert fatigue, so the design needs resilience, health monitoring, access controls, and continuous tuning.

Documentation: Use Windows Event Forwarding for intrusion detection | Microsoft Defender for Endpoint security capabilities

Maintain ransomware-resilient backups and test recovery

Ransomware-resilient backups preserve a trustworthy recovery path when production data, operating systems, or identity services are encrypted, deleted, or corrupted. Isolated and immutable copies mitigate ransomware, destructive administrators, compromised backup credentials, accidental deletion, hardware failure, and attacks intended to eliminate both systems and their recovery data.

Keep multiple protected backup copies, including a copy that is offline, immutable, or otherwise isolated from normal server and domain administrator credentials. Use separate backup administration identities, multifactor authorization for destructive operations, encryption, soft delete or immutability controls, and alerts for policy changes or mass deletion. Hypervisor snapshots alone are not an adequate backup strategy.

Back up application data and configuration as well as system state and bare-metal recovery data where required by the server role. Define recovery-point and recovery-time objectives, test file, application, system-state, and full-server restoration regularly, and record the evidence. Domain controllers, certificate authorities, and other identity infrastructure require workload-aware recovery procedures.

Implementation steps: Classify workloads and define recovery-point and recovery-time objectives, then select local, offsite, offline, and immutable backup targets appropriate to the risk. Use separate backup identities and MFA, schedule application data, configuration, system-state, and bare-metal backups as required, enable encryption and deletion protections, and monitor every job and policy change. Perform regular isolated restore tests that verify application consistency and role-specific recovery semantics for identity systems, not only successful restoration of files or virtual disks, and maintain documented recovery runbooks.

Possible drawbacks: Multiple isolated copies, immutable storage, long retention, and regular restore exercises increase storage, network, licensing, staffing, and operational costs. Backups can create false confidence when they are incomplete, stale, infected, or untested, and strong credential separation can slow routine administration, so restore validation and lifecycle management are as important as backup creation.

Documentation: Design a ransomware-resilient backup architecture | Azure Backup security best practices | Back up Windows Server system state

---

This isn't everything you can do, but it's a start. What other techniques do you use to harden your Windows Server deployments?

Cut Your Azure Blob Storage Bill in Half: A Practical Walkthrough of Object Storage TCO

Pierre_Roman — Wed, 22 Jul 2026 07:00:00 GMT

Hello Folks!

If you have ever opened your monthly Azure invoice, stared at the object storage line, and quietly wondered how it grew so much, this one is for you. At the Microsoft Azure Infra Summit 2026, Benedict Berger and George Trossell from the Azure Storage Engineering team walked through a real customer scenario and showed how to bring that bill down without touching a single application.

📺 Watch the session:

Why IT Pros Should Care

Storage is one of those services we configure once at account creation, then never revisit. Redundancy, default tier, lifecycle rules. All decided on day one, then forgotten. Meanwhile, applications get built on top, dashboards get wired up, and the bill keeps climbing in a department nobody really audits.

Here is what you get when you make storage TCO a first-class part of your operating model:

A defensible understanding of capacity, transactions, and data retrieval charges (the three real cost drivers).
Fewer surprise spikes when a cool tier read pattern runs hotter than expected.
Cost optimization that runs on its own, instead of a quarterly cleanup project nobody volunteers for.
Storage standards baked into your Infrastructure as Code, so cost-efficient defaults travel with every new account.

In short, this is one of the highest-leverage cost levers you have in Azure. And unlike compute right-sizing, you can act on most of it from the portal in an afternoon.

What Storage TCO Actually Means on Object Storage, a Technical Overview

When Benedict and George talk about Total Cost of Ownership on Azure Blob Storage, they mean four moving parts:

Capacity. The per-gigabyte cost of the data you store, which varies by access tier and by redundancy.
Transactions. Every read, write, list, and metadata call against the storage account. Priced in packages of 10,000 operations.
Data retrieval. A per-gigabyte fee that applies when you read from cool or cold tiers. It is free on hot.
Network egress. The charge for moving data out of an Azure region.

The trap most teams fall into is looking only at the per-gigabyte capacity column and picking the cheapest tier they see. That ignores the fact that as data gets cooler, transaction and retrieval costs climb sharply, and cold has a 90-day early deletion penalty that can erase your savings outright. Microsoft Learn documents this trade-off clearly in the access tiers overview, where you can see the minimum retention windows and the relationship between storage cost and access cost across hot, cool, cold, and archive.

Redundancy is the other dial. LRS keeps three copies in a single zone. ZRS spreads three copies across three zones in the region. GRS adds an asynchronous secondary in a paired region. The honest tradeoff George highlighted: redundancy protects your data, not your application. If your app is not zone-aware, ZRS alone will not keep you running through a zone outage. And GRS failover is a manual operation in most cases, with the secondary in read-only mode until you stand up new accounts to write into.

How It Works, Under the Hood

The session walked through a worked transaction example that finally made the math click for me. Picture a Spark job uploading 1,000 parquet files of 5 GB each into the hot tier, using an 8 MB block size.

Each 5 GB file is roughly 5,120 MB, divided by 8 MB blocks, which gives 640 put block operations.
One additional put block list call commits the upload, so each object costs 641 write operations.
Times 1,000 files, that is 641,000 operations, which works out to about 3.52 US dollars in that hour just for writes.

Now flip it. Read those same 1,000 files from the cool tier. The transaction count is similar, but you also pay a data retrieval fee on every gigabyte you pull back. That retrieval fee is where most teams get blindsided, because it does not show up on the hot tier at all.

Block size matters too. Larger blocks mean fewer transactions per upload. And for small objects (under 128 KB), there is a new wrinkle to plan for: starting July 2026 for existing accounts and already in effect for new accounts created from July 2025, cooler tiers bill a 128 KB minimum object size. That means a 4 KB log file moved to cool gets charged as if it were 128 KB. The fix is either to leave small objects in hot, or bin-pack them into larger objects (a TAR or ZIP, for example) before tiering them down. The Microsoft Learn page on access tier best practices covers packing strategies in detail.

Real-World Value, Use Cases, and ROI

The customer in the session went from roughly 65,000 US dollars a month to around 25,000. That is not a marketing number, it is what happens when you apply the levers in order:

Right-size redundancy. Move non-production and easily reproducible data off LRS in production. Reserve GRS for the workloads where a compliance regulation actually requires a second region.
Match tiers to access patterns. Use premium for bursty, latency-sensitive workloads. Hot for active reads and writes. Cool and cold only when you genuinely access the data infrequently and have budgeted for the retrieval fees.
Buy reserved capacity for the steady-state portion of your footprint. A one or three year commitment unlocks a discount on block blob capacity. See reserved capacity for Blob storage for terms and tier coverage.
Kill wasteful transactions. Replace polling-for-changes with change feed. Replace recurring list-blob loops with a daily or weekly blob inventory report. Use conditional request headers (If-Modified-Since and friends) so reads skip unchanged objects.
Pack small objects, or leave them in hot. Either is fine; tiering them down without packing is not.

In short, the same scenario, with the same applications, runs at less than half the cost once you actually look at it.

Getting Started

Here is the order of operations I would follow tomorrow morning:

Pull a blob inventory report on your largest storage accounts to see what is actually there: tier mix, object sizes, last modified dates, snapshots, versions.
Open the Azure pricing calculator and model your scenario with realistic transaction counts and retrieval volumes. Do not just compare per-GB prices.
Audit your redundancy choices against the workload. If an account is LRS in production with no easy way to rebuild the data, change it.
Enable Smart Tier on your zone-redundant accounts. New objects start in hot, get demoted to cool after 30 days of inactivity, and to cold after 90, with no charges for tier transitions, early deletions, or data retrieval. Anything accessed gets instantly promoted back to hot.
For accounts that cannot use Smart Tier, write a lifecycle management policy. Keep the rules simple at first: tier down after 30 days, archive after 180, expire snapshots and versions on a schedule.
Convert one of your existing lifecycle policies to ARM or Bicep, then commit it to source control. Add an Azure Policy that flags any new storage account that does not match your standard.

That last step is the one that sticks. As Benedict put it, cost optimization must become part of your system, not an afterthought.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre Roman

Feeding the GPUs: File Storage for AI and Cloud-Native Workloads on Azure

Pierre_Roman — Tue, 21 Jul 2026 07:00:00 GMT

Hello Folks!

If you are running AI workloads on Azure, you have probably learned the hard way that the wrong storage choice can leave a rack of very expensive GPUs sitting idle, waiting for data. In this session during the Microsoft Azure Infra Summit 2026, Wolfgang de Salvador and Reena Shah from the Azure Storage team walked through how Azure Managed Lustre and Azure Files map to the distinct stages of the AI pipeline, and why picking the right file system per stage is one of the highest leverage decisions you will make.

📺 Watch the session:

Why IT Pros Should Care

You probably did not get into IT to babysit checkpoint writes or debug Hugging Face egress bills at 2 a.m. But that is exactly the kind of work that lands on your plate when storage is not matched to the workload. Here is why MAIS28 matters for the IT pros, platform engineers, and Azure architects in the room:

GPU time is the most expensive compute you will ever buy. Slow data loading and slow checkpoints turn that into burned cash.
AI workloads are not one workload. Data prep, training, fine-tuning, and inferencing each have a different storage profile.
Cloud-native AI on AKS and Azure Container Apps lives or dies on the ReadWriteMany experience. If model loading is slow or shared model caches do not exist, every cold start re-downloads hundreds of gigabytes.
Storage choices ripple into security and compliance. Encryption in transit, redundancy, and snapshots are not optional in 2026.

In short, this session is for anyone who has to answer the question, “What persistent volume should we use for this AI workload?” and wants a defensible answer.

What Azure Brings to the Table, Technical Overview

Wolfgang opened with the storage profile of every stage of an AI workflow. Data preparation needs hundreds of petabytes at the best TCO (think Azure Blob Storage as the durable core). Training and fine-tuning need extreme throughput so GPUs stay fed during data loading and so checkpoint writes complete fast. Inferencing needs fast model loads, low-latency KV cache, and grounded data for RAG. One filesystem does not fit all of those at once, and trying to make it fit is where teams overspend.

Azure’s answer is a tiered, file-based portfolio that lines up with those stages:

Azure Managed Lustre (AMLFS) is a fully managed, accelerator-tier filesystem. It scales to 25 PB of capacity and up to 512 GB/s of throughput, integrates with Azure Blob Storage as the durable core, and exposes a standard Lustre client plus a CSI driver for AKS.
Azure Files is the natural ReadWriteMany choice for cloud-native AI on AKS and Azure Container Apps. It tops out at 256 TB of capacity and 10.4 GB/s of throughput, offers LRS and ZRS redundancy with snapshots and soft delete, and ships with a 99.99% SLA.
Azure Blob Storage sits underneath both of these as the cheap, durable core for data prep and long-term retention.

The mental model the speakers used is “accelerator and core”. Blob is the core, durable and economical. AMLFS is the accelerator for training. Azure Files is the accelerator for inferencing and shared state. Pick the right pair for the stage you are running.

How It Works, Under the Hood

For training, Wolfgang showed the demo most folks came to see: a 32 x H100 ND H100 v5 AKS cluster deployed from the Azure AI Infrastructure repository, running a 30B-parameter GPT-3 training job backed by AMLFS. Two things matter here.

First, AMLFS absorbs checkpoint write bursts. When 32 H100s flush state at the same time, you need a filesystem that can take the punch without stalling. AMLFS does, which keeps GPU utilization drops short and contained.

Second, the AMLFS Lustre CSI driver for AKS supports both static and dynamic provisioning with availability-zone placement, and there are five SKU tiers from MLFS20 (cheapest by capacity) to MLFS500 (cheapest by bandwidth). That means you can pick a cost-performance point that matches your training budget instead of buying the top SKU and hoping for the best.

For inferencing, Reena’s half of the session was just as practical. Five reasons Azure Files fits AKS ReadWriteMany workloads:

Standard Kubernetes RWM volume over NFS or SMB.
256 TB capacity ceiling and up to 10.4 GB/s of throughput per share.
LRS or ZRS redundancy with snapshots and soft delete for protection.
99.99% SLA so it shows up in your availability math.
Native support across AKS and Azure Container Apps, including serverless GPU.

The headline feature is Azure Files Provisioned v2. In the old model, IOPS and throughput were a function of how much capacity you provisioned, which is wrong for AI shapes that need small capacity but very high IOPS and bandwidth. Provisioned v2 splits capacity, IOPS, and throughput into three independent knobs you can dial without downtime or remount. That alone changes the economics for a lot of inferencing patterns.

The other big inferencing feature is NFS v4.1 encryption in transit, delivered with the az-nfs utility and stunnel. You get AES-GCM TLS protection on the wire, with no Kerberos and no Active Directory needed, and the application has no idea it is happening. Reena’s live demo showed an AKS pod with an encrypted NFS mount, transparent to the workload.

And then the pattern that ties it together: the shared model cache. Download the model once into Azure Files, mount it across every replica via ReadWriteMany. No per-pod cold start, no re-download from Hugging Face, no egress bill. The demo used GPT-OSS 120B with VLLM on 32 x H100, and the pattern scales down to small fine-tuned models running on serverless GPU in Azure Container Apps.

Real-World Value

The session closed with the Viton case study. Viton is a Paris-based fashion AI startup. Their image-generation platform runs on Azure Container Apps serverless GPU, with Azure Service Bus for job routing and Azure Files NFS as the shared model store. Workers pull jobs, mount the shared model cache, generate the image, and scale to zero when the queue drains. The economics only work because they are not paying to re-download the model on every cold start, and because they only pay for GPU when there is work to do.

The same pattern shows up across customer scenarios:

Training a foundation model on AKS with AMLFS as the scratch tier and Blob as the durable archive.
Fine-tuning smaller models where AMLFS checkpoints absorb the write bursts and the final artifact lands back in Blob.
Inferencing with VLLM on AKS where Azure Files holds the model weights once and every replica reads from the same RWM mount.
Serverless inferencing on Azure Container Apps with the same shared model cache pattern, but with scale-to-zero economics.

Honest tradeoff: Lustre is not the right filesystem for a 10-pod web app, and Azure Files is not the right filesystem for a 32-GPU training run. The whole point of the tiering is that you pick the right one per stage. Do not try to make one filesystem do all four jobs.

Getting Started

If you want to put this into practice this week:

Go to the Azure AI Infrastructure repository on GitHub. Wolfgang’s demo cluster came straight out of it, and you can spin up an AI-ready AKS cluster with GPU and InfiniBand operators in your own dev/test subscription.
Install the Azure Managed Lustre CSI driver on AKS if you are running training or fine-tuning. Start with a smaller MLFS SKU and size up.
Turn on Azure Files Provisioned v2 on a new share, then dial capacity, IOPS, and throughput independently to match your inferencing shape.
Enable NFS v4.1 encryption in transit with az-nfs and stunnel before you put any sensitive workload on the wire.
Try the shared model cache pattern. Pick one VLLM deployment, point it at an Azure Files RWM mount, and measure cold start time before and after.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre Roman

Premium SSD v2 and Instant Access Snapshots: A Better, Faster, Cheaper Disk for Your Azure VMs

Pierre_Roman — Mon, 20 Jul 2026 07:00:00 GMT

Hello Folks!

If you have been running Premium SSD v1 because that is just what you have always done, this session from the Microsoft Azure Infra Summit 2026 is going to be a wake up call. Raymond Lui and Adam Li from the Azure Disk Storage team walked us through Premium SSD v2 (PV2 for short) and the new Instant Access Snapshots, and the punchline is simple. PV2 is faster, it is cheaper, and the operational story around it just keeps getting better.

📺 Watch the session:

Why IT Pros Should Care

If you are an infrastructure person, a SQL DBA, an SAP Basis admin, or anyone who has ever had to right-size a VM around its storage tier, this matters to you. In short, Premium SSD v2 changes the rules around how you provision block storage in Azure. Here is what stood out from the session:

4x more IOPS and 2x more throughput compared to Premium SSD v1, on a matched configuration that costs 42% less.
Sub-millisecond average latency, with a top configuration of 800,000 IOPS and 20 GB/s of throughput on a single VM.
Capacity, IOPS, and throughput are decoupled. You dial each one independently, in 1 GB increments, instead of buying a tiered SKU.
3,000 baseline IOPS and 125 MB/s throughput included on every disk, with no extra cost.
Live Resize. You can grow disk size, IOPS, or throughput on a running VM with no restart required.
Instant Access Snapshots make restores feel actually instant, with up to 10x faster hydration and 90% lower read latency during hydration.

That is a lot of wins on one slide. Let’s break it down.

What Premium SSD v2 Is, Technical Overview

Premium SSD v2 is Azure’s purpose-built block storage for I/O-intensive enterprise workloads. Microsoft Learn describes it as designed for workloads that need sub-millisecond disk latency, high IOPS, and high throughput at a low cost. The target list is broad: SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, big data and analytics, gaming, and stateful containers running on AKS.

The architectural shift that Raymond highlighted is independent scaling. With Premium SSD v1, you bought a fixed SKU. If you wanted more IOPS, you had to buy more capacity, even if you did not need it. With PV2, capacity, IOPS, and throughput are three separate dials. You provision capacity in 1 GB increments, then you set IOPS and throughput to match what your workload actually needs. If you over-provisioned, you tune it down. If you under-provisioned, you tune it up, and the VM keeps running.

Raymond highlighted three primary use cases in the session:

SAP workloads, including SAP application VMs, SAP HANA databases, and non-HANA databases like Oracle, DB2, and SQL Server in SAP environments.
SQL Server. According to a GigaOM benchmark cited in the session, SQL Server on PV2 delivered 51% more transactions per second and 39% lower cost per transaction compared to AWS EC2, with a 9% lower 3-year TCO.
Big data and analytics replacing local SSD. This one is a bit of a surprise. On D-series VMs, PV2 delivered over 1,400 MB/s of throughput compared to 720 MB/s from local SSD. That means you can run Spark or Databricks workloads on cheaper VM SKUs (without local storage) and still get more performance than you had before.

Premium SSD v2 supports a 4k physical sector size by default, with 512E available for legacy applications. There are a few honest tradeoffs to know about. PV2 disks cannot be used as an OS disk, and they cannot be used with Azure Compute Gallery. PV2 also does not support host caching. For regions with availability zones, PV2 disks can only be attached to zonal VMs, so plan your VM placement accordingly.

How It Works, Under the Hood

Raymond covered the architecture briefly, and it is worth understanding. PV2 uses direct VM-to-storage-node communication, with 3-replica durability behind the scenes. That direct path is part of how it gets sub-millisecond latency consistently.

For Instant Access Snapshots, Adam walked through the architectural difference between the classic incremental snapshot path and the new Instant Access path. With classic incremental snapshots for PV2 and Ultra Disk, the snapshot is created, then the data has to copy in the background to Standard HDD before the snapshot is usable for restore. That copy could take a while on a large disk, and restored disks would then hydrate slowly, which dragged down read latency until hydration finished.

With Instant Access, the snapshot is usable the moment it exists. The data stays in the same high-performance storage as the source disk for a configurable duration (60 to 300 minutes, controlled by the InstantAccessDurationMins parameter). At the same time, Azure copies the snapshot data to Standard ZRS in the background for long-term retention. When the Instant Access window expires, the snapshot transitions to a regular incremental snapshot, sitting on cheap durable storage. You get the speed and the long-term durability without running two separate workflows.

In short, your VM can boot and run at near-full performance while the data hydrates in the background. There are some limits to keep in mind. Instant Access counts toward the existing limit of three in-progress snapshots per disk, and you can create up to 15 disks concurrently from all instant access snapshots of a single disk.

Real-World Value (Use Cases, ROI, Scenarios)

Adam closed his portion of the session with a BCDR demo. He cloned 12 disks of an M-series production database into a recovery VM, attached them, and was immediately running roughly 500,000 IOPS at single-digit-millisecond latency. No waiting for hydration. No degraded performance window. That is a meaningful improvement to your Recovery Time Objective (RTO).

A few scenarios where this combination really pays off:

Pre-deployment safety nets. Take an instant access snapshot before a big upgrade. If something goes sideways, roll back in seconds instead of hours.
Rapid scale-out for stateful apps. Spin up multiple disk copies of a primary instance in seconds. You can even place them across availability zones in the same region.
Dev/test environment refresh. Clone production into dev or test on demand, with full performance from the first I/O. No more “we’ll refresh dev next quarter” because the restore takes too long.
SAP HANA always-on operations. Live Resize means you can scale IOPS or throughput up on a running database during a load spike, without a maintenance window.
Right-sizing to cut spend. If you have been paying for VM SKUs purely to get local SSD throughput, PV2 may let you drop to a smaller, cheaper VM and still hit higher numbers.

One nuance came up in the live Q&A. Jens asked a great question about profiling: how do you know when PV2 is the right choice versus Standard SSD? Raymond’s guidance was direct. If the workload needs high IOPS or high throughput, PV2 is generally the right call. The VM SKU also needs to support “Premium Disk” capability for PV2 to attach, so check that compatibility first.

Getting Started

Concrete first steps so you can start kicking the tires:

Confirm region and zone support. Use az vm list-skus --resource-type disks --query "[?name=='PremiumV2_LRS']" to see which regions and availability zones are supported in your subscription.
Pick a Premium-capable VM in a supported zone. Remember, PV2 is zonal in AZ regions. Decide on the zone before you create the VM.
Provision a disk. Start with default performance (3,000 IOPS, 125 MB/s) and a small capacity. You are paying for the dials you turn up; defaults are reasonable for most starting points.
Plan your v1 to v2 migration. Raymond demoed two paths. Option A: detach the disk from a running VM and convert it (the VM keeps running on its other disks). Option B: stop and deallocate the VM, then convert in place. Both preserve data, and you can raise IOPS and throughput as part of the conversion.
Try Instant Access Snapshots. Add --instant-access-duration-in-minutes (or the equivalent ARM/PowerShell parameter) to your existing snapshot command. That is all the change you need to enable it.
For AKS users, define a storage class with skuName: PremiumV2_LRS and let dynamic provisioning take it from there.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre Roman

Network Security Perimeter for Azure Event Hubs: Hardening Your Data Streams

Pierre_Roman — Fri, 17 Jul 2026 20:26:45 GMT

What is Network Security Perimeter for Azure Event Hubs?

Azure Event Hubs now supports Network Security Perimeter (NSP), a logical network isolation boundary that lets you define a security perimeter around your PaaS resources and control public network access through perimeter-based access rules.

In practical terms, this means you can now group Event Hubs resources within a perimeter, apply consistent network access policies across them, and prevent unauthorized inbound traffic at the PaaS boundary level. It's not a firewall replacement, it's a compliance and segmentation tool that works alongside your existing NSGs and private endpoints.

Before NSP, managing network access to Event Hubs involved:

Private endpoints (which route traffic over private networks)
IP firewall rules (which block public access from specific CIDR blocks)
Virtual Network Service Endpoints (which restrict traffic to VNets)

Network Security Perimeter adds a declarative, organization-wide layer: you define which resources belong inside the perimeter, and then manage access rules once, and those policies apply consistently across all perimeter members. Changes to the perimeter automatically cascade to all enrolled resources.

Why ITPros Should Care

If you're managing Event Hubs in a regulated industry like healthcare, finance, or government, you know the pressure. Compliance auditors want proof that data pipelines are segmented, isolated, and protected from lateral movement. Network Security Perimeter directly addresses that.

Operational Value

Network Security Perimeter delivers three immediate operational wins:

Single Source of Truth for Access Rules. Instead of managing firewall rules on each Event Hubs namespace independently, you manage rules once at the perimeter level. Reduce configuration drift, reduce the attack surface, reduce human error.
Compliance and Audit Readiness. Demonstrate network isolation to auditors with a clear diagram: "All Event Hubs in the perimeter are protected by these rules." That narrative matters for SOC 2, FedRAMP, HIPAA, and PCI-DSS compliance. You can export perimeter configurations and attach them to compliance documentation.
Simplified Onboarding. When a new Event Hubs namespace joins the organization, add it to the perimeter and it inherits all access rules automatically. No manual rule-by-rule configuration. No weeks of back-and-forth with security teams.

Secondary benefits include:

Reduced blast radius during incidents, if an application is compromised, perimeter rules limit what it can access.
Simplified network topology diagrams for architecture reviews.
Faster mean time to remediation (MTTR) when security issues arise.

Real-World Example: Securing a Multi-Tenant Event Hub Deployment

Let's walk through a practical scenario. You're an ITPro at a financial services firm. You have three Event Hubs namespaces:

hubs-prod-transactions (production trading data)
hubs-prod-compliance (regulatory event streams)
hubs-staging-dev (development and testing)

Your security policy mandates:

Production namespaces should only accept traffic from specific applications (IP-restricted).
Staging can accept traffic from developer VNets but not from the internet.
All outbound access to external services must be logged and monitored.

Step 1: Define Your Perimeter

First, create a Network Security Perimeter in the Azure Portal or via Azure CLI:

az network perimeter create --resource-group rg-security --name nsp-financialservices --location eastus

This creates the perimeter container. Think of it as a logical security zone.

Step 2: Enroll Event Hubs Resources

Add your Event Hubs namespaces to the perimeter:

az network perimeter access-rule create --resource-group rg-security --perimeter-name nsp-financialservices --name allow-prod-apps --direction Inbound --access Allow --protocols Tcp --source-address-prefix 10.0.0.0/8 --destination-port-range 5671-5672

Enroll the Event Hubs namespace:

az network perimeter resource create --resource-group rg-security --perimeter-name nsp-financialservices --resource-name hubs-prod-transactions --resource-type "Microsoft.EventHub/namespaces"

You've now enrolled your production Event Hubs namespace. It inherits the "allow-prod-apps" rule, only traffic from your internal VNET (10.0.0.0/8) is permitted.

Step 3: Define Access Rules

$ns = "hubs-prod-transactions" $hub = "transactions-hub" $key = (az eventhubs namespace authorization-rule keys list --resource-group rg-prod --namespace-name $ns --name RootManageSharedAccessKey --query primaryConnectionString --output tsv)

Create rules that reflect your security policy. Allow internal compliance applications:

az network perimeter access-rule create --resource-group rg-security --perimeter-name nsp-financialservices --name allow-compliance-writers --direction Inbound --access Allow --protocols Tcp --source-address-prefix 10.50.0.0/16 --destination-port-range 5671-5672

Deny all other public traffic:

az network perimeter access-rule create --resource-group rg-security --perimeter-name nsp-financialservices --name deny-internet --direction Inbound --access Deny --protocols "*" --source-address-prefix "*" --destination-port-range "*"

Now your Event Hubs accept traffic only from specific internal subnets. Everything else is rejected at the PaaS boundary.

Step 4: Validate Connectivity

Test that legitimate applications can still reach Event Hubs:

Check logs in Azure Monitor:

az monitor log-analytics query --workspace $(az monitor log-analytics workspace list --query "[0].id" -o tsv) --analytics-query "AzureDiagnostics | where ResourceProvider=='MICROSOFT.EVENTHUB' | summarize by NetworkSecurityPerimeter_s"

If you see accepted connections logged with your perimeter name, you're good. If you see denied connections from unexpected IPs, you've caught a security issue before it impacts production.

Step 5: Monitor and Alert

Set up alerts for denied traffic:

az monitor metrics alert create --name "NSP-Denied-Connections" --resource-group rg-security --scopes /subscriptions/{subId}/resourceGroups/rg-security/providers/Microsoft.Network/networkSecurityPerimeters/nsp-financialservices --condition "avg ConnectionRejectedCount > 5" --window-size 5m --evaluation-frequency 1m --action email-admin@company.com

Now you'll be notified if someone attempts to access Event Hubs from an unauthorized source. Your security posture just went from reactive to proactive.

Technical Details: How NSP Works Under the Hood

Perimeter Architecture

Network Security Perimeter operates at the Azure platform level, not in your VNets. Here's the flow:

Connection arrives at Event Hubs public IP.
Azure evaluates the source IP/protocol against NSP rules.
If allowed, connection is routed to the namespace.
If denied, connection is dropped and logged.

This happens before TLS handshake, reducing CPU overhead and improving response times. Denied connections generate zero namespace load.

Rule Evaluation Order

NSP rules are evaluated in this order:

Explicit Allow rules (matched first wins)
Explicit Deny rules
Implicit Deny (default action)

Best practice: Create your Allow rules first (be specific about what you permit), then add Deny rules for anything not explicitly allowed. This ensures you don't accidentally block legitimate traffic.

Integration with Existing Security Tools

NSP works alongside (not instead of):

Private Endpoints: NSP adds a policy layer; private endpoints route traffic over Azure backbone. Use both.
IP Firewall: NSP provides namespace-level access control; IP firewall is still available for per-namespace rules.
VNet Service Endpoints: NSP complements VNet endpoints by adding perimeter-wide policies.
Managed Identity + RBAC: NSP is transport-layer security; identity-based access control remains separate.

Performance Considerations

NSP introduces minimal latency (<1ms typically). Azure evaluates rules in parallel and caches common decisions. For high-throughput Event Hubs:

Keep rules simple and specific (avoid wildcard ranges if possible).
Use CIDR blocks instead of individual IPs where applicable.
Monitor connection acceptance rates in Azure Monitor.

Comprehensive Resources

Official Microsoft Documentation:

Closing: Perimeter Security for Modern Data Streams

Network Security Perimeter for Event Hubs is a quiet but powerful addition to Azure's security toolkit. You get the ability to enforce organization-wide network policies without having to reconfigure every namespace individually. You can demonstrate perimeter-based isolation to auditors. You can catch lateral-movement attacks before they happen.

For ITPros managing event-driven architectures, message processors, IoT data streams, financial transactions, this capability directly improves your security posture and reduces operational overhead.

I encourage you to:

Audit your current Event Hubs deployments. How many namespaces? How many security policies are you managing today?
Design your perimeter boundaries. Group namespaces by security zone (prod, staging, dev) or by business unit.
Start with one perimeter in a dev environment. Define rules. Validate connectivity. Then expand to staging and production.
Document your perimeter architecture and rules. Include it in your security runbook and architecture reviews.
Set up monitoring and alerting. Denied connections are a leading indicator of either misconfiguration or attack attempts.

The networking challenges in cloud are complex. Network Security Perimeter gives you a declarative, policy-driven way to solve them at scale. Take advantage of it, and let me know how it changes your security workflows.

Keep your networks hardened, and your data flowing safe.

Cheers!

Pierre Roman

Az Update - Week 2 of the return editions

Pierre_Roman — Fri, 17 Jul 2026 18:37:42 GMT

Hello Folks!

This week's updates all focus on something we hear from IT pros and platform engineers all the time:

How do we make our environments more secure, more manageable, and easier to modernize without adding more complexity?

Whether you're running PostgreSQL workloads in Azure, securing Kubernetes storage, or planning your next wave of SQL Server migrations, this week's announcements bring practical improvements that can help reduce operational overhead while strengthening your overall platform strategy.

We'll look at three newly available capabilities:

Update #1 - Generally Available: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server
Update #2 - Generally Available: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS)
Update #3 - Generally Available: Expanding Azure Arc SQL Migration with SQL Server on Azure Virtual Machines

As always, I'm approaching these updates from an infrastructure and operations perspective. I'll cover why each capability matters, what to watch out for before production deployment, and some practical steps you can take to start evaluating them in your own environment.

Let's dig in.

Update #1 - Generally Available: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server

Why ITPros should care

This release brings automated security posture assessment directly into managed PostgreSQL environments. For ITPros, this matters because database security is often treated separately from infrastructure security tooling, creating blind spots and silos.

What changed is that Defender now runs native vulnerability scanning and compliance checks against PostgreSQL configurations, patches, and the ways a database could be exposed to security risks or attack opportunities. Instead of relying on external scanners or manual audits, you get platform-native assessments integrated with your existing Defender workflows.

The operational impact is significant: you can now enforce security baselines at the database layer with the same consistency you apply to VMs and network resources, reducing the gap between infrastructure and data security accountability.

Operational value

Operationally, this improves your security baseline enforcement and reduces the need for separate database security assessment tools. It also strengthens how well you can demonstrate and prove that security controls are in place and working for compliance reviews where regulators expect consistent, documented security controls.

Before production rollout, validate that Defender cost models fit your budget, that assessment frequency aligns with your change windows, and that remediation guidance maps to your patch and maintenance processes.

Prerequisites include enabling Microsoft Defender for Cloud, registering the PostgreSQL Flexible Server provider, and ensuring network connectivity so assessments can reach the database endpoint.

Real-world example with step-by-step guidance

Enable Microsoft Defender for Cloud if not already active, and ensure PostgreSQL Flexible Server subscription coverage.
Register the target PostgreSQL Flexible Server instances and confirm Defender has network visibility to the database endpoints.
Run a baseline assessment and review initial findings to understand current security posture and common remediation patterns.
Prioritise findings by severity and business impact, then schedule patches and configuration changes in maintenance windows.
Monitor ongoing assessments and track remediation progress through Defender dashboards, validating that fixes reduce exposure scores.

Technical details including code examples

This example validates that Defender is actively assessing your PostgreSQL estate. The sequence checks Defender status, confirms PostgreSQL registration, and retrieves current assessment scores.

Run these queries in a pilot subscription first to understand data structure and expected output before scaling to production databases.

az account set --subscription <subscriptionId> az security sql-vulnerability-assessment baseline show --resource-group <rg> --server-name <postgresServer> --database-name <databaseName> az security pricing show --subscription <subscriptionId> --query "[?name=='VirtualMachines' || name=='SqlServers' || name=='StorageAccounts'].[name,pricingTier]" -o table az provider show --namespace Microsoft.DBforPostgreSQL --query "registrationState" -o tsv

Expected behaviour: Defender status shows active, PostgreSQL instances are registered with the provider, and pricing tier reflects your coverage level. If assessments do not run, check network rules, managed identity permissions, and Defender plan activation. If baseline data is missing, trigger a manual scan and wait for completion.

Comprehensive Resources

Update #2 - Generally Available: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS)

Why ITPros should care

This release closes a significant gap in data protection for Kubernetes workloads consuming NFS shares from Azure Files. Previously, NFS traffic between AKS nodes and Azure Files was unencrypted, creating compliance and security risks for sensitive workloads.

What changed is that you can now enforce encryption for NFS communication at the Azure Files layer, not just at the application layer. This is important because traditional NFS lacks built-in encryption, and relying on network isolation alone is increasingly insufficient.

For ITPros managing regulated workloads (healthcare, finance, PII-sensitive data), this removes a control gap. Encryption in transit now becomes a platform-native feature instead of a workaround, reducing architecture complexity and improving auditability.

Operational value

The operational value is stronger compliance posture and reduced attack surface for data in motion between containers and storage. It also simplifies the security story when auditors ask about data protection controls.

Before enabling in production, validate that NFS-over-TLS introduces acceptable latency overhead for your workload patterns, test failover and reconnection behaviour under encryption, and confirm that monitoring and logging still work correctly.

Prerequisites include running AKS with Azure CNI or Kubenet networking, having Azure Files with NFS 4.1 enabled, and ensuring the NFS client libraries on container images support TLS.

Real-world example with step-by-step guidance

Create an Azure Files NFS share with encryption in transit enabled and confirm TLS version alignment with your security standards.
Deploy a test AKS workload that mounts the NFS share and validate that pods mount successfully with encrypted traffic.
Run performance baselines (throughput, latency, CPU overhead) before and after enabling encryption to document operational expectations.
Monitor pod logs and Azure Files metrics during the test to confirm no silent failures or unexpected throttling occurs.
Roll out to production workloads in stages, with clear rollback criteria tied to application latency and error rates.

Technical details including code examples

This example validates that your AKS cluster can successfully mount NFS shares with encryption enabled. The sequence checks cluster networking, confirms NFS connectivity, and tests mount success.

Run these commands in a non-production cluster first to validate environment readiness before touching production storage.

az aks show --resource-group <rg> --name <clusterName> --query "networkProfile.{networkPlugin:networkPlugin,networkPolicy:networkPolicy,podCidr:podCidr}" -o jsonc az storage account show --resource-group <rg> --name <storageAccount> --query "{name:name,kind:kind,accessTier:accessTier}" -o jsonc kubectl get pvc -A --all-namespaces -o wide kubectl describe pv <pvName> | grep -i nfs

Expected behaviour: cluster networking is properly configured, storage account kind supports NFS, and PVC/PV resources show NFS mount points. If mounts fail, check network security group rules, storage account firewall allowances, and subnet delegation. If latency increases, monitor resource utilisation and adjust workload placement if needed.

Comprehensive Resources

Update #3 - Generally Available: Expanding Azure Arc SQL Migration with SQL Server on Azure Virtual Machines

Why ITPros should care

This capability brings SQL Server migration into the Azure Arc operational footprint, creating a unified migration and inventory experience. For ITPros, this matters because SQL Server modernisation is often fragmented across multiple tools and teams.

What changed is that you can now discover, assess, and execute SQL migrations through Arc-native workflows, using the same permissions and governance model you already have for infrastructure and hybrid resources.

The operational gain is consistency: discovery data feeds migration planning, assessments surface blockers early, and rollout can be controlled through the same change and approvals processes you use for other infrastructure migrations.

Operational value

Operationally, this reduces tooling sprawl and improves coordination between infrastructure and database teams. Arc becomes your single control plane for tracking migration progress, managing runbooks, and collecting audit evidence.

Before production use, validate that your SQL Server inventory is complete, that migration blockers are understood and addressed, and that your maintenance windows can accommodate expected cutover timings.

Prerequisites include Azure Arc agent deployment on source VMs, Azure Database Migration Service readiness, and network connectivity to target Azure SQL resources.

Real-world example with step-by-step guidance

Deploy Azure Arc agents to SQL Server VMs and confirm all instances report healthy status with complete inventory data.
Run Arc-integrated SQL Server assessments to identify compatibility issues, dependencies, and recommended migration targets.
Pilot migration for a non-critical workload to establish runbook patterns, measure cutover time, and validate post-migration validation procedures.
Execute validation tests: connectivity, login success, database consistency checks, job execution, and application integration tests.
Scale migration in waves using documented runbooks, with gates for monitoring data health and application performance after each cutover.

Technical details including code examples

This example validates Arc agent health and SQL Server discovery completeness. The sequence ensures your Arc infrastructure is ready for migration workflows.

Run these commands as part of your pre-migration checklist to catch configuration gaps before committing to migration timelines.

az account show --output table az connectedmachine list --resource-group <rg> --query "[].{name:name,status:status,osName:osName}" -o table az resource list --resource-type Microsoft.AzureArcData/sqlServerInstances --query "[].{name:name,resourceGroup:resourceGroup,location:location}" -o table az connectedmachine machine extension list --resource-group <rg> --machine-name <vmName> --query "[].{name:name,provisioningState:provisioningState}" -o table

Expected behaviour: Arc agents report healthy status, SQL Server instances are fully discovered with accurate inventory, and required extensions are provisioned successfully. If discovery is incomplete, check Arc agent connectivity, extension deployment, and SQL service running status on source VMs. If migration pre-checks fail, verify SQL Server version compatibility and review Defender logs for blocking issues.

Comprehensive Resources

For any new capability this week, if they map to your operational roadmap, run a controlled pilot, measure the impact, and then scale with confidence. That is how you move the needle on modernisation while managing risk.

Cheers!

Pierre Roman

Azure Elastic SAN: Pooled, Cloud-Native Block Storage That Actually Acts Like a SAN

Pierre_Roman — Fri, 17 Jul 2026 07:15:00 GMT

Hello Folks!

If you have ever lived through a Friday night SAN expansion, racking new shelves and praying the zoning held together, the idea of getting that same shared block storage model in Azure (without owning a single fibre channel cable) sounds almost too good to be true. In his session at the Microsoft Azure Infra Summit 2026, Kiran Cherukuwada, Principal PM in Azure Storage, walked us through exactly how Azure Elastic SAN does that, and where it fits next to the other block storage options on Azure.

📺 Watch the session:

Why IT Pros Should Care

Most of us were taught a simple rule. One workload, one disk, size it for peak, move on. That rule has been kind to managed disks, but it gets expensive fast when you have dozens or hundreds of workloads that all peak at different times. Elastic SAN flips the model. You provision a pool of capacity and performance once, then carve volumes out of it for many workloads.

Here is why that matters for IT pros:

You stop over-provisioning each workload to its own peak; the SAN absorbs the bursts.
You get a SAN-style resource hierarchy (SAN, volume groups, volumes) that looks and behaves like the on-prem model you already know.
iSCSI connectivity means a wide compute footprint, including Azure Virtual Machines, Azure Kubernetes Service, Azure Container Instances, Azure VMware Solution, and Nutanix Cloud Clusters.
You can drive storage throughput over VM network bandwidth, which often lets you keep a smaller (and cheaper) VM SKU.

In short, if you have many IO-intensive workloads sharing one region, Elastic SAN is the lever that turns “buy peak for every workload” into “buy combined peak for the group.”

What Azure Elastic SAN Is, Technical Overview

Azure Elastic SAN is the industry’s first fully managed SAN storage service in the cloud. It brings the on-prem SAN consumption model to Azure as a single managed pool of block storage, shared across many workloads, accessed over the industry-standard iSCSI protocol.

Inside the service you get three resources, matching the on-prem mental model:

The Elastic SAN itself. Top-level resource. This is where you provision overall capacity and performance, and where billing happens.
Volume groups. Where you set network rules (service or private endpoints) and security policies. Any policy you apply here is inherited by every volume in the group, so a volume group is effectively your workload boundary.
Volumes. The LUNs that you mount on compute. They show up as raw block devices on a VM, as iSCSI targets to a Kubernetes node, or as VMware data stores on AVS.

A single SAN can scale to a petabyte of capacity, 2 million IOPS, and 80 GB/s of throughput. It is locally redundant by default, with a zone-redundant option, and shared volume support is there for clustered solutions like SQL Server Failover Cluster Instances and Azure VMware Solution. Network isolation is delivered via service endpoints and private endpoints, and data is encrypted at rest. Incremental snapshots are supported for fast point-in-time restore, and snapshots can be exported to managed disk snapshots when you need a hardened copy for backup or DR purposes.

Where does it land in the block storage portfolio? Kiran framed it simply. Premium SSD v2 is the best price/performance for dedicated per-workload performance. Ultra Disk is for the mission-critical, every-microsecond-matters workloads. Elastic SAN is the best price/performance option at scale, when you have many workloads that can share a storage pool.

How It Works, Under the Hood

The economics live in the provisioning model. You buy two types of units:

Base unit. Each base unit gives you 1 TiB of capacity plus 5,000 IOPS and 200 MB/s. Roughly 8 cents per GiB per month in East US.
Capacity-only unit. Each capacity-only unit gives you 1 TiB of capacity but no extra performance. About 25 percent cheaper, around 6 cents per GiB per month in East US.

The pattern Kiran showed is “size for performance first, then top up capacity.” A 250 TiB SAN delivering 1 million IOPS and 40 GB/s came out to roughly 200 base units plus 50 capacity-only units, landing around 20 grand per month for the whole pool.

The magic ingredient is dynamic performance sharing. With traditional disks you provision each workload to its own peak. With Elastic SAN, you provision the combined peak. So a SQL Server needing 60,000 IOPS, an AVS cluster needing 40,000, and an Oracle workload needing 100,000 IOPS look like 200,000 IOPS of dedicated disk. But if they never peak simultaneously, you can land a 150,000 IOPS SAN and let each workload hit its peak on demand. That is real money back.

The second lever is throughput over network bandwidth. Because Elastic SAN connects over iSCSI, storage I/O flows through the VM’s network pipe, not the VM’s disk throughput cap. Most VMs have far more network bandwidth than disk bandwidth, so you can drive higher storage throughput from a smaller VM SKU. That smaller SKU is cheaper to run, and (this is the quiet win) it can also cut per-core database licensing costs. As one attendee asked in the live Q&A, “Why is it possible to go beyond the VM disk throughput limit with SAN?” The answer: iSCSI traffic uses VM network bandwidth like any other VM-to-VM traffic, so the disk throttle does not apply.

One honest tradeoff: that same network bandwidth is also used by your app-tier-to-database traffic. So if you are planning to push storage hard, size the VM with both flows in mind.

Real-World Value

Where does this actually pay off?

Mixed enterprise workloads on Azure VMs. SQL Server, Oracle, custom OLTP, sharing one SAN. Kiran’s demo ran SQL TPCC, an AVS cluster benchmark, and an Oracle OLTP load simultaneously off a single 30-base-unit SAN, and the metrics blade showed exactly how each volume group consumed performance.
Extending Azure VMware Solution storage. Instead of buying expensive vSAN nodes just to grow storage, you connect AVS to an Elastic SAN datastore. Gen2 AVS private clouds skip the ExpressRoute gateway requirement and let you use a single private endpoint on the volume group.
Container Storage. Azure Container Storage v2 with Elastic SAN backing is generally available. The fast attach and detach behavior means that even if a node or cluster goes down, the data sits on the SAN and persists.
Lift and shift from on-prem SAN. Kiran shared one migration example: a workload with 100-plus vCPUs running off a mid-tier all-flash SAN array landed on Elastic SAN with roughly 64 percent TCO savings and performance that exceeded the original array.

In short, this is a “many workloads, one pool” story. If you have one heavy workload, premium SSD v2 may be a better fit.

Getting Started

Here is a practical order of operations:

Size the SAN. Add up the combined peak IOPS and throughput for the workloads you plan to consolidate, then pick base units to cover performance and capacity-only units to top up storage.
Lock down the network. Access is closed by default. Choose service endpoints or private endpoints per volume group, and open them only to the right subnets.
Place compute in the same zone. For best latency, deploy your VMs (or AVS cluster) in the same region and availability zone as the SAN.
Tune the client. Use Gen 5 (D, E, or M series) VMs with Accelerated Networking on, configure the iSCSI initiator, set up native MPIO on Windows or Linux, and use the Connect scripts from the portal which default to 32 sessions per volume.
Watch the metrics. The SAN’s Metrics tab shows transactions, ingress, and egress at the SAN, volume group, and individual volume level. Drop the granularity to one minute when you are troubleshooting.
Plan snapshots. Use Elastic SAN volume snapshots for fast dev/test restores. Export to managed disk snapshots when you need hardened backup or cross-region DR.

If you are coming from on-prem, the partnership with Cirrus Data (free in the Azure Marketplace) is the recommended path to migrate storage at the block level.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre Roman

When Compute Sits and Waits: Fixing the Hidden Storage Bottleneck in EDA and HPC with Azure NetApp Files

Pierre_Roman — Thu, 16 Jul 2026 07:00:00 GMT

Hello Folks!

If you have ever stared at an HPC pipeline and wondered why the queue depth keeps climbing while every CPU graph looks lazy, this session from the Microsoft Azure Infrastructure Summit 2026 is going to feel very familiar. Ron Hogue from the Azure Storage team and Ranga Sankar from NetApp spend twenty-seven minutes diagnosing the problem that nobody wants to admit out loud, that the bottleneck is not compute, not the scheduler, and not licenses. It is storage. And then they walk through exactly how Azure NetApp Files (ANF) solves it.

📺 Watch the session:

Why IT Pros Should Care

If you support a semiconductor, simulation, rendering, or scientific computing team, you have lived this story. Engineers ask for more cores. You buy them. Wall-clock times barely move. Managers then ask for more tool licenses, because surely that must be the constraint. Spoiler, it usually is not.

Here is why this matters to anyone running shared infrastructure on Azure:

EDA and HPC pipelines hammer storage with millions of tiny reads and writes, metadata operations like file creation, rename, and unlink, all happening concurrently across thousands of processes.
That pattern breaks generic cloud file storage that was tuned for large sequential I/O.
ANF brings the same NetApp ONTAP data services that EDA teams have used on-premises for decades, delivered as a native Azure service.
You can move design environments to Azure without re-architecting tools, schedulers, or scratch path conventions.
The economics changed in the last twelve months with the Flexible service level and Cool Access, so the old “ANF is too expensive for scratch” argument deserves a fresh look.

In short, if your job involves keeping expensive engineers and expensive licenses busy, the storage layer deserves your attention.

What Azure NetApp Files Brings to EDA and HPC, the technical overview

ANF is a first-party Azure service running NetApp ONTAP on bare-metal infrastructure inside Azure datacenters. It speaks NFS v3, NFS v4.1, and SMB, with dual-protocol options, and it preserves the file semantics that EDA tools assume. Things like POSIX permissions, fast metadata operations, snapshots, and consistent low latency.

Ron and Ranga framed the session in eight layers (Problem, Foundation, Accelerator, Scale, AI Ready, Guardrails, Optimize, Proof). Three pieces did most of the heavy lifting.

Foundation, Migration Assistant with SnapMirror. This is how you get the data into Azure without rewriting your inventory. SnapMirror replicates from on-premises ONTAP or Cloud Volumes ONTAP into ANF while preserving metadata, permissions, snapshots, and directory structure, with continuous synchronization and minimal downtime. For EDA flows where a missing ACL can invalidate an entire run, that fidelity is not optional.

Accelerator, Cache Volumes. Built on NetApp FlexCache, these volumes front your authoritative dataset (whether it lives in on-prem ONTAP or in Cloud Volumes ONTAP) and pull hot reads close to your Azure compute. Tool libraries, PDKs, shared reference data, all served at sub-millisecond latency without copying petabytes around. There is still one source of truth, which keeps your data governance story clean.

Scale, Large Volumes with Breakthrough mode. A single ANF large volume in Breakthrough mode scales to 2 PiB and delivers throughput in the tens of GiB per second by fanning I/O across six storage endpoints. That lets you collapse sharded namespaces (the classic /proj1, /proj2, /proj3 split that nobody loves) into fewer high-throughput volumes that behave predictably under contention.

How it works, under the hood

Cache Volumes are the FlexCache pattern most ONTAP customers already know. You peer a cluster, point a cache at an origin, and the cache propagates data on demand. Ron demoed this live: cluster peering with on-prem ONTAP, a cache volume created in ANF, and reads served from cache while the authoritative copy stayed home.

Large Volumes in Breakthrough mode are where the architecture gets interesting. Instead of a single mount point pinned to a single storage endpoint, Breakthrough mode exposes six storage endpoints for one logical volume. Clients can mount, balance I/O, and aggregate throughput across all six. Microsoft published Linux scale-out benchmarks showing a single 50 TiB large volume in Breakthrough mode sustaining roughly 50,000 MiB/s of sequential reads and approaching 1.8 million 8 KiB random read IOPS using twelve VMs (see the Microsoft Learn link in Resources).

For shared environments, ANF added user and group quotas with real-time consumption reporting and hard limits. Ranga demoed quota rules that stopped a runaway simulation generating millions of scratch files from starving the rest of the team. If you have ever had to send the “who filled the scratch volume” email at 2am, this feature alone might justify the trip.

On the cost side, the Flexible service level decouples capacity from throughput. You buy a capacity pool, you pick throughput independently, with 128 MiB/s of baseline throughput included and a ceiling of up to 640 MiB/s per provisioned TiB (which is roughly five times the Ultra service level). Cool Access transparently tiers cold blocks to Azure Blob behind the same file mount point.

In short, you stop paying for throughput you do not need on archival volumes, and you stop overprovisioning capacity to chase throughput on small scratch volumes.

Real-world value, use cases, ROI, scenarios

The Proof section closed with SPEC Storage 2020 EDA Blended results that are worth reading carefully:

A single large volume in Breakthrough mode sustained 2,880 EDA jobsets at about 0.51 ms overall response time.
Six volumes scaled linearly to 17,280 jobsets at about 0.60 ms.
FIO measurements approached 2 million IOPS.

The honest tradeoff: those numbers come from a benchmark, not your environment, and the SPEC tables show latency climbing at the highest load points. So treat the result as evidence that the platform behaves predictably under EDA-style concurrency, not as a guarantee for every workflow. That predictability is the part that matters. EDA leads do not lose sleep over peak throughput, they lose sleep over latency that drifts when concurrency rises.

Practical scenarios where this lands:

Burst regression and verification runs to Azure during tape-out crunches, with Cache Volumes keeping your on-prem golden tree authoritative.
Full migration of EDA environments to Azure for teams whose datacenters are out of capacity or out of lease.
HPC simulation workloads (CFD, weather, seismic, life sciences) that share the same metadata-heavy I/O profile.
AI-adjacent pipelines that need to read design data with file semantics and surface the same bytes as objects to Fabric, OneLake, or Databricks via the dual file and object access pattern Ron mentioned in the AI Ready section.

Getting Started, concrete first steps

You do not need a multi-quarter project to get a useful pilot moving.

Register the Azure NetApp Files resource provider in your target subscription and request quota in the regions you care about.
Stand up a small capacity pool, start with the Flexible service level so you can dial throughput independently.
Create a test volume, mount it from a representative VM (HBv4 or Ev5 family are good starting points for HPC and EDA respectively).
Run your real workload, not just FIO. Use a representative regression batch or simulation job and watch the metadata patterns in the ANF metrics blade.
If you have on-premises ONTAP, peer a Cache Volume against it to test FlexCache behavior with your actual datasets before committing to a full migration.
Layer in user and group quotas before you open the volume to a wider team. Trust me on this one.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here.

Cheers!

Pierre Roman

Modernize VDI with Azure Files and Entra Cloud-Native Identities

Pierre_Roman — Wed, 15 Jul 2026 07:00:00 GMT

Hello Folks!

If you have ever run a Virtual Desktop Infrastructure (VDI) estate, you know the recurring riddle. The session hosts are designed to be stateless and pooled, yet every user expects a persistent Outlook profile, their OneDrive cache, their pinned apps, and a sub-ten-second logon. In this session at the Microsoft Azure Infrastructure Summit 2026, Adam Groves and Priyanka Gangal from the Azure Files team showed how Azure Files plus Microsoft Entra ID finally let you deliver that experience without dragging domain controllers along for the ride.

📺 Watch the session:

Why IT Pros Should Care

VDI has always been a balancing act between elasticity and continuity. The compute layer wants to be ephemeral. The user wants to be at home. Bridging those two worlds used to mean a stack of identity plumbing that quietly grew until it became its own platform. This session changes that math.

Here is what jumped out for me:

Cloud-only identity for SMB. Azure Files now authenticates pure Microsoft Entra ID users and groups, including B2B guests, directly over SMB Kerberos. No on-premises Active Directory required, no Entra Connect required, no line of sight to a domain controller.
NTFS ACLs and Kerberos preserved. You keep the security model your apps already understand. Permissions still live on the file system, tickets still come over SMB, and FSLogix does not care that the identity stack underneath is different.
Performance built for the spike. Metadata caching is generally available and rolling out by default. Concurrent file handles per share are moving from 2,000 today to 10,000, with a roadmap toward 30,000 to 50,000. That means fewer storage accounts to shard across when 9 AM hits.
Zonal placement and smarter alerts. Premium LRS now lets you co-locate the share with its session hosts inside the same availability zone, and new percentage-based metrics finally make alert thresholds portable across shares of any size.

In short, the boring identity and storage plumbing that propped up VDI for a decade is being collapsed into something you can actually run as a cloud-native service.

What This Is, A Technical Overview

Let’s set the table. VDI on Azure (whether you run Azure Virtual Desktop, Citrix on Azure, or Omnissa Horizon) uses pooled session hosts. Those hosts are intentionally stateless so they can be patched, scaled, and recycled without ceremony. The user’s identity is “Connie Cloud” today, and on a different host tomorrow.

FSLogix solves the continuity half of the puzzle. It packages the user’s profile and Office data containers (the profile container and the ODFC, the Office Data Folder Container) as VHDX files that get dynamically attached when Connie logs on and detached when she signs out. Those VHDX files need to live somewhere durable, fast, and reachable over SMB from any host in the pool.

That is precisely what Azure Files delivers. It is a fully managed SMB file share service that integrates cleanly with FSLogix profile containers and App Attach image stores for AVD. The reference architecture and sizing guidance are documented on Microsoft Learn for anyone who wants the official map.

The historic friction was identity. Until recently, SMB authentication to Azure Files required either on-premises AD DS joined to the storage account or hybrid identities synced through Entra Connect. That meant keeping domain controllers (and the network paths to reach them) alive purely to satisfy storage authentication. As of this year, Azure Files supports pure Microsoft Entra ID identities for SMB Kerberos, which closes that loop.

How It Works, Under the Hood

Here is the simplified flow Adam and Priyanka walked through during the demo.

The user (an Entra-only account, no on-prem footprint) signs into an Entra-joined AVD session host with single sign-on.
The session host needs to mount the user’s FSLogix profile container from an Azure Files share.
The host requests a Kerberos service ticket. Because the share has Microsoft Entra Kerberos authentication enabled, Entra ID issues that ticket directly, no on-prem KDC involved.
The SMB connection is established, the share-level RBAC role (for example Storage File Data SMB Share Contributor) is checked, and then the directory and file ACLs (standard NTFS) are evaluated.
FSLogix attaches the VHDX, the profile loads, Outlook is happy, OneDrive is happy, and Connie’s pinned taskbar shows up exactly the way she left it.

A few details worth filing away:

Two layers of authorization. Share-level access uses Azure RBAC roles. Item-level access uses NTFS ACLs. Both still apply, which is why your existing permissions model carries over cleanly.
B2B guest support. Vendor and contractor accounts that come in as guests in your tenant can be granted access to file shares without needing a synced shadow account.
Metadata caching is the unlock. VDI is metadata-heavy: directory enumerations, file opens, renames, and closes hammer the share at logon. Metadata caching reduces P50 latency on those operations by roughly 80 to 90% and roughly doubles metadata transaction throughput, which is what makes the higher concurrent handle limits realistic. The full SMB performance reference on Microsoft Learn lays out the knobs.
Zonal placement. Premium LRS lets you pin the share to the same availability zone as your session host pool, so the SMB traffic does not bounce across zones.

Real-World Value

Where does this show up in your operations review?

Retire orphan domain controllers. Plenty of shops have a couple of DCs in Azure that exist only so Azure Files can authenticate. Cloud-native Entra ID lets you turn those off and shrink the identity attack surface.
Simpler M&A and vendor onboarding. Adding a partner organization or a new acquisition no longer requires forest trusts or a sync project. Invite guests, assign them to a group, grant the group access to the share.
Fewer storage accounts and shares to manage. Higher concurrent handle limits mean you can consolidate users that you previously had to spread across many accounts just to dodge the 2,000-handle ceiling. Less sprawl, less monitoring, fewer naming conventions to remember.
Predictable logon times at scale. Metadata caching is the kind of feature you only notice when it is missing. With it on by default, large host pools see flatter logon latency curves during the morning rush.
Operational consistency. Percentage-based metrics let you set a single rule like “alert at 10% remaining capacity” and apply it cleanly to a 5 TiB share and a 100 TiB share without bespoke thresholds.

In short, the ROI conversation moves from “how do we keep VDI running” to “how much of the supporting cast can we delete.”

Getting Started

If you want to kick the tires this week, here is a practical starting path.

Inventory your VDI identity story. Are you running hybrid because the apps need it, or because Azure Files used to need it? If it’s the second one, you have a candidate workload for cloud-only identity.
Spin up a pilot Premium SSD Azure Files share in the same region (and ideally the same availability zone) as a small AVD host pool.
Enable Microsoft Entra Kerberos authentication on the storage account. The configuration is now in the standard Azure portal, no more side trips to the fileperms portal.
Assign Azure RBAC roles at the share level (Storage File Data SMB Share Reader, Contributor, or Elevated Contributor as appropriate) to your Entra groups.
Set NTFS ACLs on the directories that will host FSLogix containers, and point FSLogix at the share’s UNC path.
Test with a cloud-only user (no on-prem identity at all) to confirm the end-to-end flow.
Turn on metadata caching and the new metrics and set percentage-based alerts so you find the limits before your users do.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here: https://www.youtube.com/playlist?list=PLjt5SKzX1iI8con7FJDB56G6hHqxGm7ki

Cheers!

Pierre Roman

Moving Petabytes Without the Panic: At-Scale Storage Assessments and Migrations to Azure

Pierre_Roman — Tue, 14 Jul 2026 07:00:00 GMT

Hello Folks!

If you have ever been asked to move all our file shares to the cloud ASAP. You already know that storage migration is one of those projects that looks easy on a slide and gets ugly in reality. In this session at the Microsoft Azure Infra Summit 2026, Anusha Subramanian and Madhuri Narayana Rao (both Product Managers on the Azure Storage team) walked through a guided roadmap for discovering, assessing, and moving large-scale storage to Azure without the homegrown scripts and the late-night reruns.

📺 Watch the session:

Why IT Pros Should Care

In short, this session matters because data migration is consistently underestimated. Anusha put it well: customers focus on migrating applications and workloads, and the big chunk of storage those apps depend on tends to be an afterthought. That afterthought is where projects go sideways. Wrong target tier, wrong tool, wrong sizing, and suddenly you are unwinding an architecture six months in.

Here is what you get out of the new tooling Anusha and Madhuri covered:

A first-party, end-to-end path from discovery to assessment to cutover, all inside services you already pay for.
File share discovery and assessment now generally available in Azure Migrate, so you stop guessing about your on-premises estate.
A fully managed online migration service (Azure Storage Mover) that handles retries, logging, bandwidth, and scheduling for you.
An offline option (Azure Data Box) for when your network is the bottleneck and you are staring down hundreds of terabytes.
A partner program (the Storage Migration Program) that covers the edge cases first-party tools do not yet cover, with the ISV software cost picked up by Azure.

If you manage file servers, NAS, or large object stores and you have a migration on your roadmap, this is your toolkit.

What This Toolkit Does: Technical Overview

The session framed large-scale storage migration as a guided roadmap with clear phases. You discover what you have on premises, assess how it is used, pick the right cloud target, decide on a migration strategy, execute in phases, and then run post-migration checks before you cut over. The point of the new tooling is to make each of those steps repeatable instead of bespoke.

Three services do most of the heavy lifting:

Azure Migrate file share assessment (generally available). Azure Migrate has been Microsoft’s first-party migration platform for a while, but until recently it was very compute-focused (think VMware, Hyper-V, and physical server lift-and-shift). The new capability extends that same discovery appliance to the file shares hosted on those servers. You get share inventory, OS type, protocol, capacity, and basic performance metrics like IOPS and throughput, all flowing back into your Azure Migrate project automatically.
Azure Storage Mover. This is the fully managed online migration service. It moves files and folders to Azure without custom scripts or migration infrastructure that you have to babysit. It supports on-premises SMB and NFS sources, cloud-to-cloud moves within Azure (for example, Blob container to Blob container), and AWS S3 to Azure Blob today (with more clouds on the roadmap).
Azure Data Box. The offline path. Ruggedized, encrypted, shipped to your datacenter, copied locally, shipped back, and ingested into Azure Storage. The current SKUs include 7 TB disks, 120 TB devices, and 525 TB devices, with 256-bit AES encryption end to end.

How It Works Under the Hood

For Azure Migrate file share assessment, you download (or update) the Migrate appliance and deploy it on your VMware, Hyper-V, or physical server estate. Grant the required permissions, and the appliance starts collecting share metadata and performance telemetry. That data flows back into your Azure Migrate project, and you see file shares appear as first-class entities in the Infrastructure tab right alongside servers. From there you can tag shares, scope them into groups, and generate assessments that map each share to a recommended Azure Files SKU, give you a TCO estimate, surface readiness blockers, and recommend a migration tool. You can export the whole thing to Excel or PowerPoint, which is exactly what you need when finance asks for the business case.

For Storage Mover, the key architectural detail is that the data path is separate from the management path. You deploy a Storage Mover agent close to your source (on premises, in another cloud, or wherever the data lives). The Storage Mover resource in Azure can sit in any region. The agent pulls data from SMB or NFS, then pushes it via REST API directly to the target storage account. Only logs and metadata flow through the service itself. That means migration velocity is governed by the proximity between the agent and the target storage account, not by the region of the management resource. SMB credentials are stored in Azure Key Vault, the agent fetches them at runtime, and one central Storage Mover resource can manage agents deployed globally.

Data Box is conceptually simpler. Order the device through the Azure portal, receive it, copy locally over your LAN at LAN speeds, ship it back, and Azure ingests the data into the storage account you specified. The Data Box family is documented at the Microsoft Learn link in the Resources section below.

Real-World Value

Where does this actually pay off? A few scenarios came up in the session.

Lift-and-shift of file servers. Discover with Azure Migrate, assess, get target SKU recommendations and TCO, then move with Storage Mover. Permissions, metadata, and folder structure are preserved during the copy.
Cloud-to-cloud (AWS S3 to Azure Blob). The session demoed the multi-cloud connector workflow: deploy a Storage Mover resource, add an AWS connector with an Inventory and Storage Data Management solution, run the AWS CloudFormation template, then create a project, a job definition, and start the job. It is portal-driven from beginning to end.
Petabyte-scale offline lift. When you cannot saturate your production WAN for weeks, Data Box gets your seed data to Azure. Then Storage Mover handles the automated delta sync so the cutover window stays small.
Recurring incremental sync. Storage Mover now supports recurring schedules (one-time, daily, weekly, or monthly) combined with bandwidth management for peak and off-peak windows. That is useful when data is being collected continuously on premises and you want predictable, throttled transfers.
Sovereign cloud. Storage Mover is now available in Azure US Government, so federal and public sector customers can run the same workflow inside their sovereign environment.
Specialized scenarios. For source-target pairs the first-party services do not cover yet (say, on-premises NetApp to Azure NetApp Files, which Anusha confirmed in the live Q&A is not yet in Azure Migrate’s scope), the Storage Migration Program brings in partners like Atempo, Data Dynamics, Cirrus Data, and Cirrata. The ISV software cost is covered by Azure.

The honest tradeoff: Storage Mover assumes a reasonable network connection between the agent and the target. If the pipe is tiny and the dataset is huge, the math does not work and you should be ordering Data Box hardware. The session was clear about this, and that kind of “use the right tool” guidance is exactly what saves projects.

Getting Started

If you are kicking off a storage migration, here is the practical sequence.

Stand up (or update) an Azure Migrate project and deploy the Migrate appliance on premises. If you already have one, just update to the latest version so file share discovery lights up automatically.
Let discovery run, then create an Azure Files assessment scoped to the shares you care about. Pick your region, redundancy, performance look-back window, and percentile utilization. Export the results to Excel or PowerPoint and use it to build your business case.
Decide online vs offline based on your dataset size and available bandwidth. Most projects can use Storage Mover. The biggest ones, or the ones with constrained WAN, start with Data Box seed data and then incremental sync with Storage Mover.
For Storage Mover, create the resource, deploy the agent close to your data, register it, define endpoints, create a project and job definition, and start the job. Configure bandwidth schedules so your production traffic does not suffer.
For specialized source-target pairs, reach out via the Storage Migration Program contact (azstoragemigration at microsoft.com) and engage a listed partner.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here

Cheers!

Pierre Roman

Build and Optimize a Data Lakehouse for Unified Data Intelligence

Pierre_Roman — Mon, 13 Jul 2026 07:00:00 GMT

Hello Folks!

Welcome back to the ITOpsTalk Blog and the Microsoft Azure Infrastructure Summit 2026 series. In this session James Baker and Sai Runtham, both from the Azure Data Lake Storage product team, take us through what a modern Lakehouse actually is, how to design one on Azure, and then they roll up their sleeves and build one end to end. If you have been hearing “Lakehouse” thrown around in architecture reviews and were not 100% sure what it changes for you as an IT Pro, this one is for you.

📺 Watch the session:

Why IT Pros Should Care

You might be thinking, “I run infrastructure, not analytics.” Fair point. But here is the thing. The lakehouse is increasingly the platform your business will run BI dashboards, AI agents, and decision support systems on, and you are the one who has to keep the data safe, governed, and reachable.

Here is what is in it for you:

It is a platform conversation. James spends a big chunk of the session on horizontal platform capabilities (storage, catalog, identity, secrets, network, policy) versus vertical pipeline concerns. That is squarely an IT Pro problem.
Data is the asset. Workspaces, query engines, and dashboards are transient. The data lives forever, and protecting it is on your plate.
Governance is what stops your data lake from rotting into a data swamp.
Scale is a virtuous cycle. More data drives more insight, which drives more data. Your platform cannot become the ceiling.
AI agents are the new consumers. They do not just read dashboards, they query gold tables directly. Your network, identity, and access controls have to keep up.

What is a data lakehouse

A data lakehouse is exactly what it sounds like. You take the cheap, flexible, schema-light scale of a data lake, and you fuse it with the low-latency query performance, update semantics, and governance of a data warehouse. One copy of the data. One place to govern it. No more forking from the lake into a warehouse just to make BI tools happy.

Quick contrast:

Data lake. Big, cheap, flexible. No schema enforced on write. Historically prone to becoming a swamp.
Data warehouse. Low-latency queries, updates, strong governance, structured. Hits a scale ceiling and costs more.
Data lakehouse. Lake-scale storage, with a high-performance query layer and warehouse-grade governance sitting over the top. No data fork.

The big shift is that the data does not move. Your BI dashboards, your AI agents, your serverless SQL queries, they all hit the same governed tables in the lake. That keeps lineage clean and your security model sane.

Building it on Azure

James and Sai are clear that the architecture is less a fixed diagram and more a list of platform capabilities you compose. Here is the shape of it on Azure.

Storage layer (the asset).

Azure Data Lake Storage Gen2 (ADLS) with hierarchical namespace turned on. That is non-negotiable for analytics workloads. It gives you atomic directory operations, POSIX-style ACLs, and the performance Delta Lake relies on.
OneLake in Microsoft Fabric if you want a tenant-wide logical lake that is built on ADLS Gen2 and stores everything in open Delta Parquet by default.

Table format and pipelines.

Open table formats: Delta Lake (and Apache Iceberg as it converges) give you ACID transactions, time travel, schema evolution, and streaming on cheap object storage.
Azure Databricks Lakeflow Declarative Pipelines with Autoloader for incremental ingestion of both batch and streaming sources straight into Delta tables. Autoloader handles new file discovery, schema inference, and evolution for you.
The medallion architecture for stamping out repeatable pipelines:

o Bronze. Raw, append-only landing zone. Source of truth.

o Silver. Cleansed, deduplicated, conformed, enriched.

o Gold. Business-ready, aggregated, performance-optimized for consumption.

Governance and identity.

Unity Catalog as the single source of truth for catalog, lineage, and fine-grained access control across bronze, silver, and gold.
Entra ID for identity. Managed identities for compute. Key Vault for secrets.
Network protection around the perimeter. The data is the crown jewel, so private endpoints, firewalls, and VNet-attached compute are baseline.

Consumption layer.

Power BI Direct Query against a serverless SQL warehouse on the gold tables. No data copies, governance flows through.
AI agents like Databricks Genie pointed at gold tables. Natural-language questions, live lineage, no data movement.

The demo that ties it together. Sai walked through a real pipeline: NYC TLC taxi trips enriched with NOAA weather and ESPN/MLB sports events, ingested by Autoloader into bronze, transformed through silver, aggregated into gold. A parallel streaming pipeline handled synthetic live events for a real-time demand view. Power BI dashboards hit gold via Direct Query. And Genie answered questions like “which zones are most sensitive to sport events” by mapping demand around Madison Square Garden, with the query and the chart generated for you. All against the same lakehouse, no data movement, full lineage.

Optimizing for cost and performance

This is where a lot of lakehouses go sideways. A few things from the session and from the official guidance worth pinning to your wall:

Get hierarchical namespace right. It is the difference between atomic directory operations and “copy then delete,” which is slow and expensive at scale.
Use storage tiers and lifecycle policies. Hot for working data, Cool or Cold for older partitions, Archive for compliance retention. Lifecycle rules on ADLS do this automatically.
Partition and file-size matter. Lots of tiny files kill query performance. Use OPTIMIZE, Z-Order, or liquid clustering on Delta tables, and partition on the columns your queries actually filter on.
Lean on vectorized reads. ADLS plus Delta plus modern query engines push a lot of work down to columnar Parquet, which keeps your compute bill in check.
Use serverless SQL warehouses where it fits. Direct Query against a serverless endpoint scales compute to demand and lets you keep dashboards fresh without import refreshes.
Observe data, not just systems. “Is Databricks up” is necessary but not sufficient. Watch data freshness, row counts, pipeline blockages, and SLAs on the data itself.
Govern everything. A well-governed lakehouse drives trust, which drives use, which drives value. Skipping governance early always costs more later.

Getting Started

If you want to put hands on a keyboard this week:

Spin up an Azure Storage account with hierarchical namespace enabled. That is your ADLS Gen2 foundation.
Stand up an Azure Databricks workspace, enable Unity Catalog, and point it at your ADLS account.
Create a Lakeflow Declarative Pipeline. Use Autoloader to ingest a sample dataset (the NYC taxi data is a classic starting point) into a bronze Delta table.
Add silver and gold notebooks or pipelines that clean and aggregate the data.
Connect Power BI to a serverless SQL warehouse on your gold tables with Direct Query.
If you are a Fabric tenant, mirror or shortcut data into OneLake and try the same pattern there, no infra to manage.
Read the Hitchhiker’s Guide to ADLS before you scale up. It will save you future you a lot of grief.

Resources

Watch the rest of the Summit

This session is one stop on a big tour. The full Microsoft Azure Infrastructure Summit 2026 playlist covers everything from sovereign cloud and AKS networking to backup, storage, and AI-assisted operations. If your job touches Azure, there is something in here for you.

Head over to the full playlist and binge what is useful: https://www.youtube.com/playlist?list=PLjt5SKzX1iI8con7FJDB56G6hHqxGm7ki

Cheers!

Pierre Roman

Welcome Back to AZ Update

Pierre_Roman — Fri, 10 Jul 2026 20:20:19 GMT

Hello Folks!

Welcome Back to AZ Update

A few years ago, Antony Bartolo and I launched a simple idea called AZ Update.

The goal was to provide a place where IT professionals could quickly understand what was changing in Azure, why it mattered, and what they should pay attention to next. The show became a weekly conversation focused on Azure news, infrastructure, operations, security, and the real-world impact of Microsoft's latest cloud updates.

Today, Azure is moving faster than ever.

Every week brings new services, platform capabilities, operational improvements, AI innovations, and architectural guidance. Keeping up is a full-time job. Most of us don't have time to read every blog post, release note, announcement, and documentation update.

That's why I'm bringing AZ Update back.

This time, as a weekly LinkedIn newsletter and this blog. To be completely transparent I am using an AI Agent to parse the update list for any in the last 7 days, filter for Infra/Ops content and research product docs and help with the draft. I do review content and write the post myself.

Each edition will cut through the noise and focus on what matters most for cloud architects, platform engineers, infrastructure teams, SREs, security professionals, and IT operators. I'll share the Azure announcements worth your attention, explain why they're important, highlight practical implications, and point you to the resources that can help you go deeper.

Just a concise weekly briefing from one ITPro to another.

If your day-to-day involves building, operating, securing, or modernizing infrastructure in Azure, Azure Arc, AKS, hybrid environments, or the growing world of AI-powered operations, this newsletter is for you.

Welcome to the next chapter of AZ Update.

Here is week 1!

This week’s Azure infrastructure updates bring practical operational gains for security, platform reliability, disaster recovery, and identity-driven access control. Here is a detailed ITPro breakdown with implementation guidance you can use in production planning.

Update #1 - Generally Available: Network Security Perimeter support for Azure Event Hubs
Update #2 - Generally Available: Confidential Computing support for Azure Event Hubs Dedicated
Update #3 - Generally Available: Support 5x churn in Azure Site Recovery
Update #4 - Generally Available: Microsoft Entra ID-based access for Azure Blob Storage SFTP

Update #1 - Generally Available: Network Security Perimeter support for Azure Event Hubs

Why ITPros should care

Network Security Perimeter for Event Hubs changes how ITPros enforce connectivity boundaries around mission-critical event pipelines. Instead of depending only on isolated firewall rules per namespace, you can apply perimeter-aware controls that are easier to govern consistently across multiple services.

From an operations perspective, this is a service-level hardening improvement. It helps reduce accidental exposure and supports better audit conversations when security teams ask for clear evidence of allowed and denied paths.

Operational value

The operational value is stronger day-two control. You can standardise network access policy patterns for producer and consumer applications, reduce policy drift, and simplify incident investigations when unexpected traffic appears.

For production rollout, validate all dependencies first: private endpoints, DNS resolution, trusted service exceptions, managed identities, and cross-subscription network paths.

Real-world example with step-by-step guidance

Inventory current producer and consumer traffic flows, including private endpoints, DNS zones, and any trusted service allowances.
Deploy a pilot Event Hubs namespace with perimeter controls in non-production and mirror realistic ingestion and consumption traffic.
Apply least-privilege inbound and outbound perimeter rules, then execute end-to-end send/receive tests with representative message volume.
Review diagnostic logs for denies, refine exceptions only where business-justified, and capture evidence for change management.
Promote to production in stages with a rollback plan that restores previous network policy if message flow health degrades.

Technical details including code examples

Use the following sequence when validating that perimeter onboarding did not break data plane operations. The first command confirms your active Azure context, the second verifies endpoint reachability, and the third validates Event Hub metadata retrieval.

Run this safely in a test window before production enforcement. If connectivity and control-plane checks pass in test, repeat with production namespace read-only checks before enabling stricter policies.

az account show --output table Test-NetConnection <namespace>.servicebus.windows.net -Port 5671 az eventhubs eventhub show --resource-group <rg> --namespace-name <namespace> --name <eventhub> --output table

Expected outcome: TCP probe to port 5671 succeeds, and Event Hub metadata query returns without auth or network timeout errors. If probe fails, check DNS, NSGs, route tables, private endpoint linkage, and perimeter rule assignment scope.

Comprehensive Resources

Update #2 - Generally Available: Confidential Computing support for Azure Event Hubs Dedicated

Why ITPros should care

Confidential Computing support for Event Hubs Dedicated matters when ITPros operate regulated or high-sensitivity event streams. It extends protection expectations beyond encryption at rest and in transit, into stronger assurances during processing.

Compared with older architectures, this reduces the need for some compensating controls and helps security and operations teams align on platform-native protections for streaming workloads.

Operational value

Operationally, this strengthens trust boundaries for event ingestion platforms that feed analytics, SIEM, and business-critical automation. It also improves evidence posture for compliance reviews where data handling controls must be demonstrated end to end.

Before rollout, validate throughput impact, partition behaviour, client compatibility, and observability baselines so confidentiality controls do not create unexpected SLO regressions.

Real-world example with step-by-step guidance

Classify Event Hubs namespaces by sensitivity and select the first dedicated environment where enhanced confidentiality requirements apply.
Enable and validate in non-production with representative producer and consumer load, including peak and burst patterns.
Measure latency, throughput, and throttling trends before and after enablement to confirm workload behaviour remains acceptable.
Capture attestation and configuration evidence required by internal security governance or external auditors.
Roll out in waves by workload criticality, with rollback criteria tied to message latency, error rates, and throttling thresholds.

Technical details including code examples

This validation example confirms namespace details and metrics health so you can compare baseline vs post-change behaviour. The metrics query focuses on ingestion, egress, and throttling signals that commonly surface operational risk first.

Run with a least-privileged operations identity that can read namespace configuration and metrics. Avoid making unrelated changes while collecting baseline evidence.

az eventhubs namespace show --resource-group <rg> --name <namespace> --output jsonc az monitor metrics list --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.EventHub/namespaces/<namespace> --metric IncomingMessages OutgoingMessages ThrottledRequests --interval PT5M az account show --query user.name -o tsv

Expected outcome: namespace query succeeds, metrics return consistently, and no abnormal throttling spike appears after control changes. If results diverge, review dedicated capacity planning, partition strategy, RBAC scope, and workload profile fidelity.

Comprehensive Resources

Update #3 - Generally Available: Support 5x churn in Azure Site Recovery

Why ITPros should care

Higher churn support in Azure Site Recovery is directly relevant for ITPros protecting write-intensive systems. It expands what can be replicated reliably, reducing DR exceptions for fast-changing workloads.

Compared with the previous operational envelope, this gives more room for modern transactional applications while still requiring disciplined capacity and replication health management.

Operational value

Operational value is improved DR coverage and better alignment between production write behaviour and recovery plans. Teams can protect more workloads without bespoke workaround architecture.

For production rollout, validate process server sizing, bandwidth headroom, cache storage performance, and sustained replication lag during peak change windows.

Real-world example with step-by-step guidance

Baseline current churn and replication lag for candidate workloads to identify which systems benefit most from the increased support.
Enable replication in a pilot for one high-churn workload and observe initial seeding and steady-state health.
Run test failover and reprotect to verify recovery objectives and operational runbook completeness.
Tune bandwidth and cache settings if lag increases during peak write intervals or backup overlap windows.
Onboard additional workloads incrementally and use replication health gates before each expansion wave.

Technical details including code examples

These commands are relevant for validating actual recovery readiness instead of configuration-only status. They expose protected item health and support controlled failover rehearsal.

Use a non-production network for test failover and document outputs so operations and business continuity stakeholders share the same readiness evidence.

az site-recovery fabric list --resource-group <rg> --vault-name <vault> -o table az site-recovery protected-item list --resource-group <rg> --vault-name <vault> --fabric-name <fabric> --protection-container <container> -o table az site-recovery recovery-plan test-failover --resource-group <rg> --vault-name <vault> --name <recoveryPlan> --network-id <testNetworkId>

Expected outcome: protected items remain healthy, lag remains within target, and test failover completes without consistency errors. If failures occur, inspect connectivity, process server capacity, cache throughput, and policy mappings.

Comprehensive Resources

Update #4 - Generally Available: Microsoft Entra ID-based access for Azure Blob Storage SFTP

Why ITPros should care

This launch modernises SFTP access for Azure Blob Storage by bringing identity control closer to Microsoft Entra. ITPros gain stronger governance options than local-account-only models for many enterprise scenarios.

Operationally, the key change is identity lifecycle alignment: provisioning, review, and revocation can be managed with central identity processes instead of fragmented local credentials.

Operational value

The value is reduced credential sprawl, better auditability, and clearer access accountability across teams and external partners exchanging files over SFTP.

Before production, validate client compatibility, RBAC scope, network restrictions, access review cadence, and emergency break-glass procedures.

Real-world example with step-by-step guidance

Confirm SFTP is enabled on the storage account and validate networking model (public endpoint restrictions or private access path) matches policy.
Assign Entra-based permissions with least privilege and validate scope at storage account and container boundaries.
Test SFTP authentication and file operations using approved clients while collecting diagnostic logs for audit evidence.
Validate joiner-mover-leaver scenarios by changing membership and role assignments, then confirming access updates propagate correctly.
Roll out in stages by partner or workload segment with clear support ownership and incident response runbooks.

Technical details including code examples

This sequence verifies account capability and role assignment posture before user acceptance testing. It is useful for catching scope mistakes that often cause authentication-success/data-access-failure patterns.

Run safely by using a dedicated test identity and non-production storage account first; then repeat read-only validation in production before broad enablement.

az storage account show --name <storageAccount> --resource-group <rg> --query "{name:name,isSftpEnabled:isSftpEnabled,allowBlobPublicAccess:allowBlobPublicAccess}" -o jsonc az role assignment list --assignee <principalObjectId> --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<storageAccount> -o table az account show --query user.name -o tsv

Expected outcome: SFTP capability is enabled, expected role assignments are present, and test identity can perform allowed operations only. If sign-in works but file actions fail, inspect RBAC propagation delay, ACL/permission scope, and storage network restrictions.

Comprehensive Resources

If you are planning adoption, start with one workload per update area, collect operational evidence, and standardise the validated pattern in your runbooks and IaC modules. That approach keeps change safe while accelerating delivery.

Cheers!

Pierre

Stop Hand-Building VMs at 2 AM: Automated Image Pipelines with Azure Image Builder and Compute Gallery

Pierre_Roman — Fri, 10 Jul 2026 07:00:00 GMT

Hello Folks!

If you have ever stood up a marketplace Ubuntu VM, SSH’d in, layered on your monitoring agent, security tooling, a couple of CA certs, and a hardening script, then captured the result and called it your “golden image,” I have bad news. That image was already drifting from the next one your coworker built before you finished naming the snapshot. At the Microsoft Azure Infra Summit 2026, Sandeep Raichura (PM for Azure Compute Gallery) and Kofi Forsen (PM for Azure VM Image Builder) rebuilt the whole workflow the right way. Source, customize, validate, distribute, deploy. No clicks. No tribal knowledge. No 2 AM heroics.

📺 Watch the session:

Why IT Pros Should Care

You carry the pager when a bad image rolls into ten regions. You explain why three teams have three different Ubuntu 22.04 baselines with three different agents. You find out at 2 AM that someone deleted “the old image” and the old image was the one production VMSS was still pulling.

This session is in your lane. It covers:

Why hand-rolled images stop working the moment a second team needs one.
How Azure VM Image Builder (AIB) turns image creation into declarative pipeline code.
How Azure Compute Gallery handles versioning, replication, sharing, and accidental-deletion protection.
How automatic image creation triggers chain a marketplace update through your golden image, into every downstream image, with zero manual steps.
How VM Scale Sets close the loop with rolling upgrades and automatic OS upgrade.

In short, this is the practitioner version of “do VM image management properly,” from the PMs who own both services.

What is Azure Image Builder and Azure Compute Gallery

The two services do different jobs and you really do need both.

Azure VM Image Builder is the build engine. You hand it a JSON template that declares:

A source (marketplace image, managed image, VHD, or existing gallery version).
Customizers (shell, PowerShell, Windows updates, file copies, restart steps).
One or more distribute targets (usually a Compute Gallery image definition).

AIB spins up a temporary build VM, runs your customizers in order, validates, generalizes, captures, and publishes. Every build runs the exact same way. No SSH, no RDP, no “I forgot to install the monitoring agent this time.”

Azure Compute Gallery is the management layer for the resulting artifacts. Formerly Shared Image Gallery, it has three levels:

Gallery. The top-level container. Sharing policy lives here: RBAC, Direct Shared Gallery, or Community Gallery.
Image definition. The metadata. OS type, generation, security type, publisher / offer / SKU. The SKU of an image family.
Image version. The actual replicated artifact. Controls regions, replica counts, storage type (ZRS by default), end-of-life date, and the safety flags.

AIB writes the artifact. Compute Gallery stores, versions, replicates, and shares it.

Building an automated image pipeline

The session walked through the five steps a real pipeline needs, with no manual intervention in the critical path:

Source. A marketplace image or any other base.
Customize. Scripts that install agents, harden, configure, and validate. Stored in a storage account so AIB can pull them with the right managed identity.
Validate. Built-in validation hooks plus your own smoke tests baked into the customizer. Fail fast. Do not silently continue.
Distribute. Push the captured image to a Compute Gallery image definition. Pick your regions and replica counts here.
Version. Compute Gallery handles semantic versioning, replication, and safety flags.

The trick that makes this a real pipeline is the two-template pattern Kofi demoed:

A source template builds the org-wide golden image from the marketplace base. Its source reference is set to latest for the marketplace SKU (for example, Canonical Ubuntu 22.04 latest).
A distro template layers user-group-specific tooling on top of the golden image. Its source reference is the golden image gallery version, also set to latest.

Both templates get an automatic image creation trigger attached. Triggers only fire when the template references latest. From that point on:

Canonical publishes a new Ubuntu 22.04. The source template’s trigger fires, AIB rebuilds your golden image, and a new version lands in the source gallery.
That new golden image version fires the distro template’s trigger. AIB rebuilds every downstream distro image automatically.
VM Scale Sets configured for automatic OS upgrade pick up the new image version and roll it out in batches, pausing if the Application Health probe goes red.

You set it up once. After that you only come back when you want to change something on purpose.

Safety by design in Compute Gallery

A bad image at the top of this chain takes out thousands of VMs at the bottom. Sandeep was clear: safety is not optional, it is built in. The four features worth turning on every time:

ZRS storage by default. Image versions stored on zone-redundant storage so a zonal failure does not take the image down.
Exclude from latest. Stage an image into a region without making it the default for new deployments. Flip the flag when you are ready to roll. You can set this globally on the version or per region.
Block deletion before end-of-life. The image cannot be deleted until its end-of-life date. This is the flag that stops the 2 AM accidental delete.
Soft delete. If everything else fails, soft delete gives you a recovery window to restore an image version that should not have been removed.

Combine those four with a sane end-of-life date on every version and your blast radius drops dramatically.

Real-world scenarios

A few patterns that came up in the session and the Q&A:

Multi-region fleets. Define your target regions in the AIB template. AIB hands the artifact to Compute Gallery and Compute Gallery does the replication. Your scale sets in every region pull a local replica, not a cross-region copy.
Open-source publisher. Use a Community Gallery so anyone in Azure can deploy your image. You provide a contact URL and email at the gallery level so consumers know where to file issues.
Partner sharing. Use Direct Shared Gallery to grant specific subscriptions or tenants access without making the image public.
VM Scale Sets with rolling upgrade. Reference the image definition (not a specific version) when you create the scale set. The scale set tracks latest. Pair it with a rolling upgrade policy and the Application Health extension. AIB publishes, Compute Gallery replicates, the scale set rolls, and the rollout pauses itself if the Application Health probe goes red.

Getting Started

Pick the highest-pain item and start there. You do not have to do this all at once.

Stand up a Compute Gallery in one region. Create one image definition with proper publisher / offer / SKU metadata. Turn on soft delete at the gallery.
Wrap an existing build script in an AIB image template. Use a marketplace image as the source. Distribute to your new gallery.
Add excludeFromLatest, endOfLifeDate, and the block-deletion flags to your image version. Default to ZRS storage.
Register the Microsoft.VirtualMachineImages and the triggers feature. Attach an automatic image creation trigger to the template. Set the source reference to latest.
Build a second template that takes your golden image as its source. Attach a trigger to that one too.
Create a VM Scale Set that references the image definition and enable automatic OS upgrade with rolling upgrades and the Application Health extension.

That is the loop. Source updates flow through automatically. Bad images do not delete each other. Fleets roll forward in batches.

Resources

Azure VM Image Builder overview. The service concepts, supported OS, regions, and capabilities.
Azure Compute Gallery overview. Gallery, definition, version, replication, and sharing.
Azure VM Image Builder best practices. Identity, networking, customizers, and operational guidance from the product team.
Automatic Image Creation with Image Builder triggers. Step-by-step to wire up source-image triggers.
Create an image definition and image version. Portal, CLI, PowerShell, and REST flows for publishing artifacts.
Automatic OS image upgrades for VM Scale Sets. The closing leg of the pipeline.
Share images using Community Gallery. Public, non-commercial sharing for open-source publishers.
Azure Image Builder samples on GitHub. Reference templates, customization scripts, and end-to-end examples.

Watch the rest of the Summit

This session was one of many at the Microsoft Azure Infrastructure Summit 2026. If you want the keynotes, the IaC deep dives, the AKS sessions, and the rest of the infra track, the full playlist is here:

Microsoft Azure Infra Summit 2026 playlist

Cheers!

Pierre Roman

Deployment Stacks: Treating Your Azure Deployments Like Real Resources

Pierre_Roman — Thu, 09 Jul 2026 07:00:00 GMT

Hello Folks!

If you have ever come back from vacation to find a “mystery” storage account no one remembers creating, or watched a junior admin nuke a production resource because they clicked the wrong tile in the portal, this session is for you. Sydney Smith from the Azure Deployments team walked through Deployment Stacks at the Microsoft Azure Infrastructure Summit 2026, and the message is simple: classic Azure deployments are just history records, and history records cannot protect anything.

Deployment Stacks change that. A stack is a real Azure resource. It has a resource ID. It supports RBAC. It tracks what it owns. It can refuse to let people break it. That is a real upgrade to how we run Infrastructure as Code in Azure, and IT pros should be paying attention.

📺 Watch the session:

Why IT Pros Should Care

Let me cut through the noise. Here is why this matters to anyone running Azure infrastructure:

Orphaned resources cost real money. Classic deployments do not track ownership. Remove a resource from your template, and the live resource sits in Azure forever, billing you and adding security risk.
Deployment history is fragile. Anyone can groom it away. You lose the audit trail.
There is no native change protection. Without stacks, the only thing standing between your production VNet and a midnight portal click is RBAC discipline. That is not enough.
Drift is invisible. You cannot detect what you cannot define as the source of truth.
No unified view. Resources scattered across resource groups or subscriptions are hard to manage as one unit.

Stacks give you a single lifecycle aware unit, with built in guardrails, that you can govern with RBAC and policy like any other Azure resource. That is the kind of plumbing IT operations has been asking for.

What are Deployment Stacks

A deployment stack is a native Azure resource that manages a group of resources as one lifecycle aware unit. It is the modern evolution of Azure deployments. Where a classic deployment is a record of what happened, a stack is a living thing that knows what it owns.

Key facts to anchor on:

A stack is of type Microsoft.Resources/deploymentStacks. It is a first class Azure resource.
A stack can span multiple resource groups and even multiple subscriptions.
You feed it a Bicep or ARM JSON template, the same files you already have. No rewrite required.
It produces a snapshot of the resources it manages, and uses that snapshot for lifecycle decisions.

Two feature sets do the heavy lifting:

Resource lifecycle management. Creates, updates, and deletes across scopes are managed as one operation.
Resource change protection. Stacks can apply deny assignments on the resources they manage, blocking changes that did not come through the stack itself.

That second point is the one that changes how you think about safety in production.

How Deployment Stacks change your workflow

Honestly, the syntax change is tiny. If you know az deployment group create, you already know az stack group create. Same template, same parameter files, same scope. You just swap deployment for stack and add a couple of new parameters.

What changes in the day to day:

Your template becomes the source of truth. Remove a resource from Bicep, and the next stack run can clean it up automatically. No more manual hunt and delete.
You get a portal view. The stack resource shows you what it manages, what is detached, and what the deny settings look like.
You can clean up everything in one step. Deleting a stack with the right unmanage setting tears down all its resources and the empty resource groups, without you mapping out dependency order.
Pipelines get cleaner. The bicep-deploy GitHub Action and the equivalent Azure DevOps task speak stacks natively. Create, validate, what-if, delete. Same shared package on the backend, so features hit GitHub and ADO at roughly the same time.

The honest tradeoff: stacks are powerful enough to delete things at scale. That is the whole point. So you need to think harder about which mode you pick.

Deny settings and lifecycle control

Two parameters carry most of the weight, and you need to understand both before you push a stack into production.

action-on-unmanage controls what happens when a resource leaves the template:

detachAll: resources stay in Azure, the stack stops tracking them. This is the default and the safest. No delete operation. Good when you are still learning stacks.
deleteResources: resources are deleted, the resource group stays.
deleteAll: full cleanup. Resources go, empty resource groups go. This is what you pair with strict deny settings if you want the template to be the only source of truth.

deny-settings-mode controls who can change what:

none: no protection. Anyone with RBAC can do anything. Use this only when you really mean it.
denyDelete: blocks delete operations. Updates are still allowed.
denyWriteAndDelete: the strict one. No changes outside the stack. This plus deleteAll makes your template the absolute source of truth.

A handy escape hatch: excludedActions lets you punch specific resource types or operations through the deny wall. For example, you can deny delete across the board but allow deleting your managed identities or storage accounts. Use this sparingly. Every exception is a future ticket.

A few honest tradeoffs to keep in mind:

denyWriteAndDelete is strict on purpose. Portal admins will get permission errors. That is the feature, not a bug. Train your team.
deleteAll is permanent. Pair it with what-if before every change so you do not nuke something by accident.
Resources should not be managed by two stacks. The deny assignments from each stack will fight each other and block updates. If two apps share a SQL database, pull it in as an existing resource rather than dual managing it.
Stacks are not just for Bicep. They consume ARM JSON templates today. Terraform users do not get the same first party stack experience, so if you live in Terraform world, stacks are not your tool.

Getting Started

You do not need a giant rollout plan. Pick something small and learn the parameters in a safe environment.

A practical path:

Pick a non production Bicep template you already trust. Anything that creates a small set of resources in one resource group works.
Deploy it as a stack with safe defaults. Use actionOnUnmanage=detachAll and denySettingsMode=denyDelete. You get protection without risking accidental deletes.
Try removing a resource from the template and redeploy. Watch how the resource shows up as detached in the portal. Get comfortable with what that looks like.
Graduate to deletes. When you trust the workflow, switch to deleteResources or deleteAll in a dev environment. Always run what-if first.
Adopt Stacks What-If. The newer Stacks What-If commandlet triangulates the stack snapshot, the live resource state, and the desired state from your template. The result is a far less noisy diff than classic what-if, and the RBAC model only needs read access on the what-if resource for follow up gets. Big win for production review workflows.
Wire it into your pipeline. The bicep-deploy GitHub Action and the Azure DevOps task both support type: deploymentStack with create, validate, and delete operations. Start with a create pipeline, then add a what-if pipeline for PR validation, then a cleanup pipeline that uses delete to tear down ephemeral environments.

If you hit an out of sync error between your stack and Azure, the bypass-stack-out-of-sync-error parameter lets the pipeline reconverge automatically instead of forcing a manual cleanup. Read the docs before you flip it on, but it saves real time when state drifts.

Resources

Watch the rest of the Summit

If this session helped, there are plenty more where it came from. The full Microsoft Azure Infrastructure Summit 2026 playlist covers everything from Azure Local and Azure Files to AKS networking, SRE agents, and the keynote with Jeremy Winter. Worth a binge if you run Azure infrastructure for a living.

Microsoft Azure Infrastructure Summit 2026 playlist

Cheers!

Pierre Roman

Lock Down AKS End to End with Application Gateway for Containers and Managed Cilium L7

Pierre_Roman — Wed, 08 Jul 2026 07:00:00 GMT

Hello Folks!

If your AKS cluster looks like most production clusters I have walked through, one of two things is true. Either nobody writes any network policies and every pod can talk to every other pod, so one compromised container blows up the entire blast radius. Or somebody wrote a few coarse rules along the lines of “namespace A talks to namespace B over port 80”, which sounds secure right up until an attacker realizes that port 80 is exactly where they were planning to live anyway. Real attacks happen at Layer 7, dressed up like ordinary HTTP traffic, and L3 / L4 plumbing cannot tell the difference.

That is the gap session MAIS09 from the Microsoft Azure Infrastructure Summit 2026 closes. Vyshnavi Namani and Darshil Shah from the Azure Networking product team walked through how two AKS-managed add-ons, Application Gateway for Containers (AGC) and Cilium L7 via Advanced Container Networking Services (ACNS), can lock down the entire path from the public internet to a single pod. No NGINX. No external WAF appliance. No third-party CNI to babysit.

📺 Watch the session:

Why IT Pros Should Care

Let me cut to the chase. If you operate AKS clusters today, this session matters because:

You probably still have an ingress controller and an external WAF stitched together with annotations and prayers. AGC plus ACNS collapses that stack into first-party add-ons that AKS owns end to end.
Both Application Gateway for Containers and Advanced Container Networking Services are generally available. This is not a preview demo, this is production.
Security is finally readable. Every rule is a YAML object. Code review, audit, GitOps. No more “what does this NGINX config map even do anymore” archaeology.
It actually works on a real attack pattern. The demo shows WAF killing a SQL-injection-style GET that Cilium would have happily forwarded, because the method (GET) was on the allow list.

If you have ever had to explain to an auditor why a single compromised pod could pivot across your whole cluster, this is your exit ramp.

The AKS Security Gap This Closes

Most clusters are protected by a load balancer at the edge and basically nothing inside. The cluster door looks like a vault, but the hallways are wide open. Cilium calls this the lateral movement problem, and it is exactly how Kubernetes attacks unfold in the wild. Compromise a pod, then phone home, then pivot.

What MAIS09 demonstrates is something different. AGC is the L7 front door (the metal detector at the lobby). ACNS Cilium L7 is the lock on every pod’s office door. Both speak HTTP. Both enforce identity. Both are managed by AKS itself.

The legacy alternative, Application Gateway Ingress Controller (AGIC), bolted a full Application Gateway onto your cluster through a translator. Two services, two lifecycles, two finger-pointing teams when something broke. AGC is the successor, built from scratch for Kubernetes, speaking the Gateway API natively, enabled with a single AKS flag. AKS provisions the controller, wires the identity, delegates the subnet, and owns the upgrades. You own the policies.

AGC + Managed Cilium, End to End

Here is the mental model from the session. Picture four concentric layers of defense between the public internet and a pod.

AGC front end. One Azure resource, one public DNS name, and (thanks to the Kubernetes Gateway API) multiple hostnames behind the same IP. The demo runs Contoso, Fabrikam, and Adventure Works on a single AGC public IP using three HTTPRoute objects. One infrastructure, three websites. Real cost savings, real ownership clarity (platform owns the Gateway, app teams own the HTTPRoutes).
Azure WAF on AGC. This is the content inspector. It runs the OWASP Core Rule Set (DRS 2.1 in the demo) against every incoming request, looks for SQL injection, cross-site scripting, path traversal, and the rest of the OWASP Top 10, and returns a 403 before the packet ever touches your pod. Microsoft maintains the rule set, you bind it to AGC via a SecurityPolicy.
ACNS Cilium L7 ingress on every pod. This is where identity-based policy lives. Rules key off pod labels, not IPs, because IPs change every time the cluster autoscaler does its job. The demo uses an allow-agc-l7-get-only CiliumNetworkPolicy that lets the AGC backend reach the tenant pods, but only with GET or GET /products. Anything else, POST, PUT, DELETE, gets a Cilium-synthesized 403 before NGINX ever sees the request.
ACNS east-west and egress policy. Two more policies do the heavy lifting inside. client-may-call-contoso-get-only lets the client pod reach Contoso with GET, and only Contoso. A default-deny baseline blocks everything else (pod-to-pod and pod-to-internet) with a single carve-out for kube-dns on port 53.

The magic is that the same Cilium engine handles north-south, east-west, and egress with one consistent identity model. eBPF in the Linux kernel does the enforcement on the same node as the pod, so the decision happens before the packet leaves the host. No sidecars, no iptables sprawl, no daemonset you need to upgrade by hand.

Real-world Scenarios

The demo walks through six tests and the results map directly onto things you are probably trying to solve right now:

Multi-site hosting on one IP. Three hostnames, one AGC, three 200 OKs from three different backend pods. If you are paying for three load balancers today, you can stop.
WAF blocks a malicious GET that ACNS would have let through. This is the punch line of why you need both layers. The method (GET) is on the Cilium allow list, but the payload is a SQLi pattern. WAF returns 403 at the edge. Defense in depth, working as advertised.
Method enforcement at the pod door. GET returns 200, POST/PUT/DELETE return 403, GET /admin returns 403, GET /products returns 200. Cilium is doing actual HTTP inspection, not just dropping packets.
East-west enforcement with readable verdicts. Client to Contoso GET is 200. Same client, same destination, POST is 403 (L7 deny, TCP completed). Client to Fabrikam is 000 (L4 drop, no TCP handshake). Reading the difference between 403 and 000 is now a debuggable signal, not a mystery.
Default-deny egress kills phone-home. A pod tries to reach bing.com. DNS resolves (the carve-out works), TCP SYN goes nowhere, wget gives up with exit code 1. If that pod was compromised and trying to exfiltrate data, this is where the attack chain dies.
Selective allow still works. Same pod, same tools, but a DNS lookup against kube-dns inside the cluster returns instantly. We did not unplug the network. We locked it down with a purpose.

Honest tradeoffs to call out. The session does not pretend everything is free. AGC introduces a billed subnet association and a managed identity you do not manage in BYO mode. Cilium L7 needs the Cilium data plane (ACNS Container Network Security features are Cilium-only). The Envoy proxy that handles L7 inspection has a cost only when you actually enforce L7, which is a fair deal in my book.

Getting Started

If you want to try this on a cluster of your own, three flags do most of the work on az aks create:

--network-dataplane cilium (turns on the eBPF data plane)
--enable-acns (enables Advanced Container Networking Services, including Hubble observability and Cilium L7 policy)
--enable-app-routing or the ALB add-on flag (provisions the AGC controller as an AKS-managed add-on)

From there you write four YAML objects: a default-deny CiliumNetworkPolicy, an allow-DNS carve-out, an AGC ingress allow with method and path constraints, and your east-west allow rules. The session repo includes the full set so you can clone and follow along.

One bonus worth knowing about. ACNS ships Hubble out of the box, with pre-built Azure Managed Grafana dashboards. Flow logs, service maps, policy hit counts. Even on pods that are not yet under L7 enforcement, you get observability for free. When something breaks at 2 a.m., you have an audit trail instead of a tcpdump.

Resources

Watch the Rest of the Summit

If MAIS09 hit the spot, there are dozens more sessions in the same playlist covering AKS networking at scale, Azure Local, AVM, the new Deployment Agent, and a lot more. Grab a coffee and binge.

Microsoft Azure Infrastructure Summit 2026 playlist

Cheers!

Pierre Roman

Modern Ingress for AKS: Introducing Application Gateway for Containers (AGC)

Pierre_Roman — Tue, 07 Jul 2026 07:00:00 GMT

Hello Folks!

This Microsoft Azure Infra Summit 2026 sessions one is for everyone running production workloads on AKS. Jack Stromberg from the Application Gateway product team walked us through the entire history of load balancing in about ten minutes (no small feat) and then dropped the news that Application Gateway for Containers (AGC) is picking up a brand new trick: AI gateway capabilities through the CNCF Gateway API Inference Extension. If you have ever watched one pod get hammered while the others sit idle, this session is going to feel personal.

📺 Watch the session:

Why IT Pros Should Care

The NGINX Ingress Controller retirement is pushing a lot of teams to pick a new front door for their AKS clusters. AGC is Microsoft’s managed, Azure-native answer. It is Layer 7, it speaks both the Kubernetes Ingress API and the newer Gateway API, and it runs outside the cluster so you are not paying with pod CPU to terminate TLS.

Here is the short list of why this session matters:

The internet runs on load balancers, and the load balancer story has been mostly stable for decades. That is changing fast.
AI inference traffic does not look like web traffic. Long-lived, GPU-bound, expensive. Traditional Layer 7 rules cannot keep up.
AGC now ships AI gateway capabilities (in preview) that route by model, route by load, and stop slamming a busy pod when others are idle.
Measured numbers from the demo: zero timeouts versus 15 failed requests, and a P99 time-to-first-token of about 1,000 ms versus 16,000 ms on a vanilla HTTPRoute.

If your AKS clusters are starting to host self-hosted models alongside regular services, you need to know this exists.

What is Application Gateway for Containers

AGC is the evolution of the older Application Gateway Ingress Controller (AGIC). The architecture is the part that matters:

Application Gateway for Containers resource: the managed Azure resource that actually handles traffic, TLS, WAF, and routing.
Frontends: listeners and IP addresses that accept incoming traffic.
Associations: the link between the AGC resource and your AKS VNet/subnet.
ALB Controller: a small controller that runs inside your AKS cluster, watches your Gateway API and Ingress resources, and reconciles the AGC configuration in near real time.

Two deployment models. You can let the ALB Controller manage the lifecycle of the AGC resource for you, or you can go Bring Your Own (BYO) and manage it with Bicep, Terraform, ARM, or the CLI. I like BYO for production because it gives the platform team a clean separation between Kubernetes intent and the Azure resource lifecycle.

Feature-wise it covers what you would expect from a modern Layer 7: automatic retries, autoscaling, zone resiliency, weighted/split traffic for blue-green, header and URL rewrites, WAF integration, mTLS (front, back, or end-to-end), HTTP/2, WebSocket, gRPC, and server-sent events. Routing by hostname, path, header, query string, or HTTP method.

How AGC works with AKS

Jack opened with a tour of the OSI model that I genuinely enjoyed. The TL;DR:

Layer 4 (network load balancer): stateless, fast, simple. Source IP, destination IP, send. This still powers most of the internet.
Layer 7: TLS, session affinity, WAF, mutual auth, intelligent routing based on the contents of the request. This is where modern web applications live.
Kubernetes ingress: the Layer 7 load balancer is no longer a hardware appliance you rack and stack. Pods come and go constantly. You need a controller that translates Kubernetes intent into load balancer config in near real time.
Gateway API: the CNCF’s vendor-neutral way to express that intent. AGC is a first-class Gateway API implementation, so the YAML you write is portable across clouds and on-prem.

In Gateway API land you work with three primary resources:

A Gateway (the front door, including listeners and hostnames).
An HTTPRoute that says “for requests matching this host/path/header, send them to this backend.”
A backend, traditionally a Kubernetes Service.

That is the picture for normal web apps. AI workloads break it.

Real-world value

Here is the honest tradeoff Jack laid out. Traditional Layer 7 load balancers were tuned for short-lived, low-latency requests. They distribute traffic with simple algorithms (round robin, least connections) because they assume backends are interchangeable.

AI inference flips every one of those assumptions:

Requests are long-lived. A model reasoning over a big prompt can take many seconds.
Backends are not interchangeable. Pod A might be running an image model, Pod B a coding model.
Compute is expensive. GPUs are not cheap, and a hot pod with a full KV cache cannot just accept more work.
A traditional load balancer will happily pile new requests on a pod that is already saturated, while idle pods sit waiting.

The fix is the CNCF Gateway API Inference Extension. It introduces four primitives, and AGC implements them so you do not have to bolt the pieces together yourself:

Body-Based Router (BBR): reads the prompt body to pull out the requested model. In AGC, this runs inside the load balancer itself. Nothing extra for you to deploy.
Endpoint Picker (EPP): runs in your cluster, scrapes metrics from your model pods (things like KV cache utilization), and tells the load balancer which pod is actually a good target right now.
InferencePool: a new Kubernetes resource that groups pods serving the same model along with the EPP and target port.
InferenceObjective: lets you express priority when multiple requests are competing for the same pool.

The neat part is that InferencePool plugs in as a backendRef on an HTTPRoute, right next to traditional Service backends. You can mix AI and standard workloads behind the same gateway. No new gateway, no new product, just an additional backend type.

Jack ran two demos that I want to call out:

Model-aware routing: a script fires curl requests with different prompts. AGC’s body-based router pulls the requested model out of the JSON body, sets a header, the HTTPRoute matches the header, and traffic lands on the right InferencePool. The vanilla HTTPRoute side cannot do this and a lot of requests fail.
Load-aware routing: three pods, one already busy. Fire 50 requests at the AI-enabled route and 50 at the traditional route. The endpoint picker steers traffic to the idle pods. P99 time-to-first-token: about 1,000 ms with AGC’s AI gateway, about 16,000 ms without. Timeouts: zero with AGC, 15 without.

That is a real number, on the same backend, in the same cluster. The only thing that changed is the load balancer knowing what is happening behind it.

Getting Started

If you want to try this, here is the path I would take:

Stand up an AKS cluster with Azure CNI, OIDC issuer, and Workload Identity enabled. AGC needs these.
Register the providers: Microsoft.ContainerService, Microsoft.Network, Microsoft.NetworkFunction, Microsoft.ServiceNetworking.
Create a user-assigned managed identity for the ALB Controller and grant it the AGC Configuration Manager role.
Install the ALB Controller via Helm or as an AKS add-on, then create your Gateway resource against the azure-alb-external GatewayClass.
Start with a plain HTTPRoute against a regular Kubernetes Service. Get that green first.
When you are ready for inference, deploy your model, drop in an InferencePool and an Endpoint Picker, and point your HTTPRoute at the pool.

Pierre’s tip: the AI gateway capabilities are in preview. The team explicitly asked for feedback from anyone running self-hosted models in AKS, especially around model mix, request patterns, and what you are doing today to keep hot pods from getting buried.

Resources

Watch the rest of the Summit

Catch every session from the Microsoft Azure Infra Summit 2026 on the official playlist: https://www.youtube.com/playlist?list=PLjt5SKzX1iI8con7FJDB56G6hHqxGm7ki. There is a companion session on AKS Security with AGC and Managed Cilium that pairs really well with this one.

Cheers!

Pierre Roman

Best practices for Infrastructure as Code CI/CD on Azure

Pierre_Roman — Fri, 26 Jun 2026 07:00:00 GMT

Hello Folks!

If your IaC repo has a dev folder, a test folder, and a prod folder that all started out identical and have since drifted in three different directions, this session is for you. At the Microsoft Azure Infrastructure Summit 2026, Jack Tracey and Jared Holgate (the team behind Azure Landing Zones and Azure Verified Modules) laid out, in plain language, how to ship Infrastructure as Code on Azure without leaking secrets, blowing up production, or duplicating thousands of lines of module code across folders. Here are the bits that matter most for IT Pros and platform engineers.

📺 Watch the session:

Why IT Pros Should Care

You are the one paged at 2am when a pipeline rolls out a broken NSG rule. You are the one carrying the cert that the deploy service principal still uses. You are the one explaining to audit why the prod plan and the prod apply ran with the same Owner-scoped identity.

So this session is squarely in your lane. It covers:

Why hand-rolled modules are slowly becoming an anti-pattern on Azure.
A repo layout that scales to dozens of environments without copy-paste.
How to get rid of static client secrets and federated cert auth, for good.
Where approvals actually need to live in GitHub vs. Azure DevOps so they cannot be bypassed.
The three-layer Terraform state model that Microsoft uses inside Azure Landing Zones.

In short, this is the practitioner version of “do IaC properly,” from the people who write the platform code Microsoft ships.

The IaC CI/CD problem

Jack opened with a slide that gets a knowing laugh from anyone who has been doing this for more than a year. You start with one repo, one Bicep file, one happy team. Eighteen months later, you have a landingzone-prod-v2-final-USE-THIS-ONE folder, a service principal whose secret expired two days ago, and a pipeline nobody dares touch.

The drivers of that pain are consistent:

Modules written from scratch, never tested the same way twice.
Per-environment folders that diverge silently over time.
Long-lived secrets and certificates sitting in pipeline variables.
One identity doing both plan and apply, with Owner on the management group.
No approvals, or approvals in the wrong place.
No tests until the deploy fails in prod.

The good news is none of these problems are new, and the patterns to fix them are well understood. The session walks through them in the order you would actually adopt them.

Patterns that work in production

1. Don’t write modules. Consume Azure Verified Modules.

This is best practice number one, and Jack and Jared spent a full chapter on it for a reason. Azure Verified Modules (AVM) is the official Microsoft initiative that consolidates IaC modules for Azure into a single, supported, Well-Architected-aligned library, available in both Bicep and Terraform. The Bicep versions live in the Public Bicep Registry under the avm/ namespace. The Terraform versions live on the HashiCorp Terraform Registry under Azure/avm-*.

What you get for free when you consume an AVM module:

Defaults that line up with the Well-Architected Framework (RBAC over access policies, TLS 1.2, private endpoint support out of the box).
Semantic versioning so you can pin and review the diff before upgrading.
Deployment tests on every module, run by the AVM team.
A real Microsoft support path, not a random GitHub issue.

A great backchannel question came up about brownfield. Jared’s answer: AVM is just standard IaC, no special tooling. In Bicep, brownfield adoption is straightforward because there is no state. In Terraform, the new import blocks make it less painful than it used to be.

2. One folder, one source of truth

Repo layout is where most teams go wrong, and the fix is simple. You should have one set of module code, and per-environment differences should be expressed as data, not as duplicated code. In Bicep, that means a single main.bicep and one .bicepparam file per environment. In Terraform, the same main.tf with one .tfvars file per environment.

If you find yourself copying a module folder to dev, test, and prod, stop. Within six months those three folders will not look the same, and at that point you no longer have IaC, you have three handwritten environments that happen to be checked into Git.

3. Kill static secrets. Use Workload Identity Federation.

This was the chat highlight. The question came in: “So in short, replace all service principals with credential secrets with user-assigned managed identity?” Jack and Jared both replied within seconds: yes, 10 points to you.

Workload Identity Federation (OIDC) lets your GitHub Actions or Azure DevOps pipeline exchange a short-lived token from its own OIDC provider for a Microsoft Entra ID token. No client secrets, no certs to rotate, no Key Vault dance to retrieve them.

A couple of things to know:

Subject claim format differs by platform. GitHub uses repo:org/repo:environment:prod style claims; Azure DevOps uses sc://org/project/connection. Pick the right one or auth silently fails.
Use a user-assigned managed identity as the target. It survives the pipeline being deleted and gives you one place to manage role assignments.
The Azure Bicep Deploy GitHub Action and the official AzureRM / AzAPI Terraform providers all support OIDC natively.

4. Split plan from apply

Even with OIDC, a single Owner-scoped identity that does both terraform plan and terraform apply is a problem. Plan needs Reader (and a few read-data permissions). Apply needs Contributor or Owner depending on what you deploy. Split them into two identities, federated to two different stages of your pipeline, and you have a real least-privilege story to take to your security team.

Securing the pipeline

Auth is half the story. The other half is making sure only the right pipelines, with the right approvals, can use those identities at all.

Governed templates. Keep reusable pipeline templates in a separate, locked-down repo. Pin federated credentials or service connections to those templates via the job_workflow_ref claim on GitHub or required template checks on Azure DevOps. If someone forks the workflow, the OIDC exchange refuses to issue a token.
Approvals in the right place. On GitHub, use Environments and require reviewers on prod. On Azure DevOps, put the approval on the Service Connection, not the Environment. The Environment approval can be bypassed by a clever YAML author. The Service Connection approval cannot.
Shift left, hard. Pre-commit hooks for bicep format and terraform fmt, lint on every PR, GitHub Advanced Security for secret and code scanning, automated tests on PRs, and ephemeral test environments spun up per PR and torn down at the end. One attendee mentioned using Pester for end-to-end infra tests against a sandbox sub. That is exactly the pattern.
Three-layer state. For Terraform on Azure Landing Zones, the recommended split is: platform landing zone (one state), application landing zone / subscription vending (one state per landing zone), application workload (one state per workload). Never collapse all subs into one state file. You will regret it the first time someone runs apply at the wrong time.

Getting Started

You do not have to do all of this at once. Pick the highest-pain item first.

Still using client secrets in pipelines? Fix that this sprint. Wire up OIDC and a user-assigned managed identity.
Drifting per-environment folders? Consolidate to one module plus per-env param files.
Writing your own storage account module for the fifth time? Try the matching AVM module from the registry.
Put approvals on the Service Connection (ADO) or Environment (GitHub) for prod.
Add linting and pre-commit hooks.
Split plan and apply identities.
Layer your Terraform state.

It is a roadmap, not a weekend project. Every step pays back the moment you take it.

Resources

Azure Verified Modules portal. the official AVM home, with module indexes for Bicep and Terraform, specs, and FAQ.
Azure Verified Modules on GitHub. the tracking repo and source of truth for module proposals.
Bicep on Microsoft Learn. official language docs, deployment guidance, and references for the public registry.
Azure Bicep Deploy GitHub Action. the OIDC-friendly action for deploying Bicep from GitHub Actions.
GitHub Actions for Azure on Microsoft Learn. Workload Identity Federation setup for GitHub Actions targeting Azure.
Configuring OpenID Connect in Azure (GitHub Docs). the canonical OIDC subject claims and federated credential walkthrough for GitHub.
Azure Pipelines documentation. service connections, approvals and checks, required templates, and YAML reference.

Watch the rest of the Summit

This session was one of many at the Microsoft Azure Infrastructure Summit 2026. If you want the keynotes, the Bicep deep dives, the AKS sessions, and the storage track, the full playlist is here:

Microsoft Azure Infra Summit 2026 playlist

Cheers!

Pierre Roman

Building Secure, Well-Architected Azure Workloads with Azure Verified Modules and GitHub Copilot

Pierre_Roman — Thu, 25 Jun 2026 07:00:00 GMT

Hello Folks!

If you have been writing Bicep or Terraform for Azure over the last few years, you have probably lived this story. You pick a community module, it works great for six months, then the maintainer moves on, issues stop getting answered, and you are stuck owning code you never wrote. At the Microsoft Azure Infra Summit 2026, Jack Tracy and Jarrod Holgate (tech leads on the Azure Verified Modules project) walked us through how AVM solves that, and how pairing it with GitHub Copilot and Spec Kit changes the way IT pros build Azure workloads.

📺 Watch the session:

Why IT Pros Should Care

This is not a developer-only topic. If you are the person responsible for landing zones, platform engineering, or the IaC pipelines that other teams ship through, this hits you directly.

You stop owning home-grown storage account and VNet modules that no two teams write the same way.
You get secure-by-default resources without having to draft a 40-page internal coding standard.
You can let application teams move fast without sacrificing the Well-Architected Framework guardrails you care about.
You get a supported, Microsoft-backed module library with a clear lifecycle, instead of betting on an abandoned repo.
You finally have a deterministic way to put AI to work on infrastructure code without it inventing things you do not want in production.

If any of that sounds like a Tuesday for you, this session is worth 40 minutes.

What are Azure Verified Modules

Azure Verified Modules (AVM) is the official Microsoft infrastructure-as-code module library for both Bicep and Terraform. Jack put it plainly in the session: AVM is the one-time solution that is not going to go away, with ownership, a defined lifecycle, structure, and well-defined specifications.

Here is what makes AVM different from the previous landscape of community repos:

It is supported in multiple IaC languages today (Bicep and Terraform), with consistent specifications across both.
Modules are aligned to the Azure Well-Architected Framework by default. Zone redundancy on, public IPs off, sensible TLS minimums, right out of the box. Everything is still flexible, you can override any of it via a parameter or variable.
It is open source. People inside and outside Microsoft can contribute and maintain modules.
It consolidates the older CARML and Terraform Verified Modules efforts under one roof, owned by Microsoft FTEs and backed by the AVM core team.

AVM has three module classifications, and understanding them is half the battle:

Resource modules. A one-to-one mapping to a single resource type, like a storage account or a virtual network. Need ten of them, loop the module ten times.
Pattern modules. A collection of resources, usually built on top of resource modules, that delivers a bigger slice of an architecture. The Azure Landing Zone is roughly five pattern modules behind the scenes.
Utility modules. Helpers you probably never call directly, but that the library uses for things like region lookups, SKU availability, and naming standards.

One thing that gets undersold: AVM is not just for you. The Azure Developer CLI templates use it. Azure Landing Zone and Sovereign Landing Zone are built on it. Internal Microsoft service teams use it. When you adopt AVM, you are using the same building blocks Microsoft uses.

Pairing AVM with GitHub Copilot

This is where the session gets interesting. AVM gives you the trusted Lego bricks. GitHub Copilot gives you a coding assistant. The problem, as Jack called out, is that AI is non-deterministic by default. It is great at solving ambiguous problems, but you cannot just point it at a blank repo and trust it to stamp out production infrastructure.

That is the gap spec-driven development is designed to fill.

Spec-driven development is a documentation-first approach. Instead of telling Copilot “write me a Terraform module for a hub-spoke network,” you write a structured specification up front that captures intent, quality bar, security requirements, and coding standards. The AI then uses that spec as the contract, generates code, validates against it, and loops until the output matches what you asked for.

Jarrod walked through Spec Kit, the open source toolkit maintained by GitHub and Microsoft, which formalizes this into eight steps:

Constitution. The non-negotiables. “We must use AVM. We must comply with PCI. Optimize for cost.” This is your project DNA.
Specify. What you actually want to build, focused on user goals and outcomes, not implementation details.
Clarify. Copilot scans the spec, finds ambiguities, and asks you targeted questions (IP ranges, bastion SKUs, anything that is fuzzy).
Plan. A technical plan that maps the spec to your standards and constraints.
Checklist. A quality checklist the agent uses later to validate its own work.
Tasks. The plan broken down into small, reviewable steps.
Analyze. A consolidated report across the spec, plan, and tasks so you can sanity check the whole package.
Implement. Copilot finally writes the code, validating against everything above as it goes.

The critical detail: at every one of those gates, you review. You are still the human in the loop. The AI is not flying solo, and you are not signing off on a thousand-line code dump.

When you wire AVM into the constitution (“use AVM modules wherever possible”), Copilot stops trying to hand-roll raw resource declarations. It composes solutions out of trusted, tested, WAF-aligned modules. That is what makes the combination so powerful.

Spec Kit is not the only option. Jack mentioned two others worth knowing about:

OpenSpec. Leaner than Spec Kit, brownfield-first, aimed at smaller experienced teams.
Squad. A completely different model built by a Microsoft team. No specs. Instead, a virtual team of agent personas (IaC specialist, UX, deployment, an orchestrator called Ralph) that collaborate to deliver work. Worth a look if your style is more agent-team than document-first.

Real-world value

So what does this actually buy you when Monday morning hits?

Speed without sacrificing the bar. Application teams stop writing storage account boilerplate. They focus on what the workload needs to do, and the AVM modules handle the resilient, compliant defaults.
Compliance becomes additive, not a rewrite. If you need to add HIPAA or NIST compliance later, you add another spec on top of your existing constitution and iterate. You do not throw out your modules.
Less ambiguity loop, fewer tokens burned. A good spec up front means fewer Copilot iterations. You get to a working answer faster, with less back and forth.
Trust in the AI output. Because AVM modules are tested, supported, and WAF-aligned, what Copilot stitches together is built on solid foundations. You can review the spec instead of every line of Terraform.
Your developers shift up the stack. They stop writing IaC primitives and start designing architectures and requirements. That is where the business value lives anyway.

A note on tradeoffs. AVM modules are intentionally generic and flexible, so you sometimes get parameters you do not need, and the well-architected defaults can be opinionated for your scenario. The fix is simple, override the parameter. You are trading some control for a lot of consistency, and for most teams that trade is the right one.

Getting Started

If you want to try this for yourself, here is the path I would take:

Go to aka.ms/AVM and bookmark it. Everything starts there.
Browse the Bicep and Terraform module indexes. Find the resource you would normally hand-write and try the AVM version in a dev subscription.
Read the AVM specifications so you understand the contract every module follows. It makes the parameter sets a lot less surprising.
Install Spec Kit via the Specify CLI (the GitHub repo has the instructions) and try the AVM example under the experimental “AI-Assisted Solution Development” section on the AVM site.
Run the eight-step Spec Kit flow against a small workload. Do not start with your production landing zone. Pick something contained, like a single app with a web tier, a database, and a Key Vault.
Keep the human in the loop. Review every spec gate. That is where the quality comes from.

Resources

Watch the rest of the Summit

If you found this useful, there is a lot more where it came from. The Microsoft Azure Infra Summit 2026 playlist covers landing zones, deployment stacks, AKS networking, storage, and the AI side of platform operations. Block out an afternoon and binge it.

Microsoft Azure Infra Summit 2026 on YouTube

Cheers!

Pierre Roman

Deploy an Azure Landing Zone in About Twelve Minutes with the ALZ IaC Accelerator

Pierre_Roman — Wed, 24 Jun 2026 07:00:00 GMT

Hello Folks!

Welcome back to my coverage of the Microsoft Azure Infra Summit 2026. This session is one I have been looking forward to, because if you have ever stood up an Azure Landing Zone (ALZ) by hand, you know it can eat weeks. Management groups, policy assignments, Hub-and-Spoke networking, log analytics, Defender for Cloud, identities, pipelines, governed branches. There is a lot of plumbing.

In this session Jack Tracy (he leads the Azure Landing Zones team) and Jarrod Holgate (tech lead on Azure Landing Zones and Azure Verified Modules) walk through the ALZ Infrastructure as Code Accelerator. Then they actually run it, and a bootstrap that used to be a multi-week journey wraps up in about twelve minutes of typing and ticking boxes.

📺 Watch the session:

Why IT Pros Should Care

If you are the person who has to deliver a secure, governed Azure platform before your dev teams can land their first workload, this matters to you. Here is the short version of why:

It bakes in the Cloud Adoption Framework “start right, stay right” pattern so you do not have to invent it.
It supports both Bicep and Terraform, and it bootstraps GitHub or Azure DevOps for you (with a local file system option for GitLab, Bitbucket, or whatever else you run).
It covers roughly 80% of common customer scenarios out of the box. You do not have to write modules from scratch.
It is open source, every module is published, and you can fork or compose as you see fit.
It is now built entirely on Azure Verified Modules (AVM), so what you deploy is aligned with the Well-Architected Framework by default.

In short, if you have been hand-crafting management group hierarchies and policy assignments in the portal, stop. There is a better way, and the team that designs ALZ ships it as code you can actually read.

What is the ALZ IaC Accelerator

A quick recap, because it is worth getting the vocabulary right.

The Azure Landing Zone lives inside the CAF Ready methodology. It is the shared platform (networking, identity, logging, policy, management groups) that supports the many application landing zones your workload teams consume. Jack uses a great analogy in the session: think of a metropolis. Before residents and businesses can move in, you need water, gas, electricity, and roads. The platform landing zone is the utilities layer. The application landing zones are the buildings.

The ALZ IaC Accelerator is the tooling that deploys and manages that platform layer using declarative infrastructure as code. It is composed of:

A set of IaC modules in Bicep and Terraform (all of them built on AVM).
A bootstrap layer for GitHub or Azure DevOps (or local file system).
The ALZ PowerShell module, published to the PowerShell Gallery, which orchestrates everything.
Comprehensive docs covering prereqs, scenarios, and options.

The accelerator is a Microsoft-supported, open source path to a production-grade landing zone. You should look at it before you decide to roll your own.

How it works

The accelerator runs in four phases. Jarrod walks through each of them in the demo.

Phase 0: Plan. You make decisions: Bicep or Terraform, GitHub or Azure DevOps, single or multi-region, Hub-and-Spoke or Virtual WAN, Azure Firewall or NVA, DDoS on or off, and so on.

Phase 1: Prereqs. Before the accelerator runs, you need two things in place: an identity to run the bootstrap, and the platform subscriptions. Traditionally this was four (connectivity, identity, management, security). There is now a new lighter option that needs only two subscriptions for smaller environments.

Phase 2: Bootstrap. This is where the magic happens. You feed it a bootstrap configuration file plus a platform landing zone configuration file, then run the Deploy-Accelerator command. The PowerShell module deploys identities, optional Terraform state storage with private networking, optional self-hosted container-instance runners, and then sets up your repositories, pipelines, environments, governed pipeline templates, and OIDC-based service connections using Workload Identity Federation. No manual steps after Phase 2.

Phase 3: Deploy. Run the CD pipeline. The platform landing zone deploys. Done.

A few things worth highlighting about the bootstrap:

The accelerator deploys two identities: one with read-only for plan / what-if, one with write for apply / deploy. Least privilege, out of the box.
Pipelines are governed. The actual deployment pipeline lives in a separate template repository, so changes to it require an approval.
A CI pipeline runs on pull requests automatically. You get the engineering hygiene without configuring it.

Real-world scenarios and when to use it

Jarrod calls these “scenarios” and “options”. They are the difference between picking a starting pattern (scenario) and tuning it (options).

Scenarios. There are 11 of them out of the box. Pick the one that matches your starting state:

Single region, Hub-and-Spoke, Azure Firewall.
Multi-region, Hub-and-Spoke, Azure Firewall.
Single or multi-region with Virtual WAN.
Single or multi-region with a third-party NVA.
No-connectivity (governance only, no Hub networking) for organizations who are not ready for centralized networking yet.
New scenarios 10 and 11, which are cost-optimized for small and medium businesses with around 10 workloads. Same modules, same orchestration, just a smaller, cheaper starting shape.
Sovereign landing zone for customers with data sovereignty and confidential compute requirements.

Options. Once you pick a scenario, you can tune it. The 16 documented options are the ones the team sees customers ask about most often: customizing resource names, customizing management group names, turning the DDoS protection plan on or off, choosing the sovereign baseline, and more. Behind those, Terraform alone exposes hundreds of variables.

Honest tradeoffs (because Pierre always tells you the rough edges):

OpenTofu is not supported today. Just Bicep and Terraform.
Personal Access Tokens are still required for Azure DevOps and self-hosted agents at the time of the session. The team has confirmed CLI / managed identity support is on the roadmap.
Brownfield is “it depends”. The accelerator is greenfield-friendly. Retrofitting an existing tenant is possible but is going to depend on your current state and your risk appetite.
You still own decisions. The Lady Justice slide in the session is a great reminder: balancing dev team freedom with central governance is your job. The accelerator gives you the controls; it does not pick your policy posture for you.

Getting Started

If you want to try this without waiting, here is the path Jarrod actually demoed:

Install the ALZ PowerShell module from the PowerShell Gallery.
Create your platform subscriptions (two minimum, four for the classic layout) and an identity for the bootstrap.
Run Deploy-Accelerator with no parameters. It will prompt you interactively for everything: region, parent management group, subscriptions, naming convention, self-hosted agents yes or no, private networking yes or no, PAT, project name, and approvers.
Review the two generated configuration files: the bootstrap config and the platform landing zone tfvars (or Bicep params).
Confirm. The bootstrap runs Terraform behind the scenes and wires up Azure plus your repos.
Run the CD pipeline. Approve at the apply stage. Your platform deploys.

If you are not ready to drive Terraform directly, the Azure Migrate AI agent (in preview) wraps the exact same accelerator codebase behind a guided chat experience. You answer questions, it produces a zip with the same two config files plus a design document explaining the decisions it made. Then you hand that off to the same pipeline. The Azure MCP server has matching tooling for VS Code, so day-two changes like “turn off the DDoS protection plan” know to also uncomment the dependent policy assignments in the archetype files. That is the kind of context-aware editing that saves you from breaking your own deployment.

Resources

Watch the rest of the Summit

If you found this useful, the full Microsoft Azure Infra Summit 2026 playlist has a lot more: deployment stacks, Bicep beyond the basics, IaC CI/CD best practices, AVM with GitHub Copilot, and plenty of AKS and storage sessions. Grab the playlist here: Microsoft Azure Infra Summit 2026 on YouTube.

Hit the ALZ team in the comments on the session, or open an issue on the repo. The team is genuinely active there.

Cheers!

Pierre Roman