Az Update – Week 2 of the return editions

Hello Everyone!

This week, we’re diving into updates that cater to a common concern among IT professionals and platform engineers:

How can we enhance the security, management, and modernization of our environments without complicating matters further?

If you’re using PostgreSQL on Azure, looking to secure Kubernetes storage, or preparing for upcoming SQL Server migrations, the announcements this week provide practical enhancements. These updates can help reduce operational overhead and bolster your overall platform strategy.

We’ll explore three new features now available:

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

As always, I’ll discuss these updates from an infrastructure and operations angle. I’ll explain why each feature is important, what to consider before deploying them into production, and share practical steps for evaluating them in your environment.

Let’s get started!

The latest release introduces automated security assessments within managed PostgreSQL environments. For IT professionals, this is crucial as database security often operates in silos separate from infrastructure security, which can lead to vulnerabilities.

With this update, Microsoft Defender now conducts vulnerability scanning and compliance checks directly on PostgreSQL configurations, patches, and potential exposure points to security threats. This integration allows for seamless assessments without relying on external scans or manual audits.

This significant operational improvement means you can enforce security standards consistently across your databases, just as you do for VMs and network resources, bridging the gap between infrastructure and data security accountability.

Operationally, this enhances your enforcement of security standards and reduces the necessity for additional database security tools. It also strengthens your ability to demonstrate compliance by ensuring that security measures are documented and effective during audits.

Before rolling this out in production, ensure that Defender’s cost models fit within your budget, align the assessment frequency with your change management timelines, and match remediation guidance with your patching and maintenance processes.

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

1. Activate Microsoft Defender for Cloud if you haven’t already and ensure PostgreSQL Flexible Server subscription coverage is in place.
2. Register your PostgreSQL Flexible Server instances and confirm that Defender can access the database endpoints.
3. Conduct a baseline assessment and review your initial findings to understand your current security posture and identify common remediation patterns.
4. Prioritise findings based on severity and business impact, then schedule patches and configuration updates within maintenance windows.
5. Keep tabs on ongoing assessments and track remediation progress via Defender dashboards, making sure that fixes effectively lower your exposure scores.

This example validates that Defender is actively assessing your PostgreSQL estate. Run the following queries in a pilot subscription first to familiarise yourself with the data structure and expected outputs before transitioning to production databases.

az account set --subscription  
az security sql-vulnerability-assessment baseline show --resource-group  --server-name  --database-name 

az security pricing show --subscription  --query "[?name=='VirtualMachines' || name=='SqlServers' || name=='StorageAccounts'].[name,pricingTier]" -o table

az provider show --namespace Microsoft.DBforPostgreSQL --query "registrationState" -o tsv

Expected outcome: Defender status shows as active, with registered PostgreSQL instances and appropriate pricing tiers reflecting your coverage. If assessments don’t execute, check network rules, permissions, and Defender plan activation. If baseline data seems absent, trigger a manual scan and await its completion.

1. Azure update: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server
2. Microsoft Defender for Cloud overview
3. Azure Database for PostgreSQL security
4. SQL vulnerability assessments in Defender for Cloud
5. Enable Defender for Cloud

This release addresses a critical gap in data protection for Kubernetes workloads that rely on NFS shares from Azure Files. Previously, NFS traffic between AKS nodes and Azure Files was unsecured, posing compliance and security threats for sensitive workloads.

Now, you can enforce encryption for NFS communication at the Azure Files layer, beyond just the application layer. This change is crucial since traditional NFS does not support built-in encryption, and relying solely on network isolation is increasingly inadequate.

For IT professionals managing workloads in regulated sectors (such as healthcare, finance, or dealing with personally identifiable information), this feature eliminates a substantial oversight. Encryption in transit is now seamlessly integrated into the platform, rather than being a workaround, ultimately reducing architectural complexity and enhancing auditability.

Operationally, this enhancement strengthens your compliance posture and reduces the vulnerabilities associated with data in motion between containers and storage. It also simplifies your security narrative when questioned by auditors about data protection measures.

Before activating this in production, ensure that NFS-over-TLS does not introduce unacceptable latency for your workload patterns, test failover and reconnection behaviour under encryption, and check that your monitoring and logging functions correctly.

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

1. Create an Azure Files NFS share with encryption in transit enabled, and verify that TLS versions align with your security protocols.
2. Deploy a test AKS workload that mounts the NFS share, ensuring pods mount successfully with encrypted traffic.
3. Perform performance baselines (throughput, latency, CPU usage) before and after enabling encryption to document operational expectations.
4. Monitor pod logs and Azure Files metrics during testing to confirm that no silent failures or unexpected throttling occur.
5. Progressively roll out to production workloads, defining clear rollback criteria related to application latency and error rates.

This example verifies that your AKS cluster can successfully mount NFS shares with encryption enabled. Run these commands in a non-production cluster initially to confirm environment readiness before working with production storage.

az aks show --resource-group  --name  --query "networkProfile.{networkPlugin:networkPlugin,networkPolicy:networkPolicy,podCidr:podCidr}" -o jsonc

az storage account show --resource-group  --name  --query "{name:name,kind:kind,accessTier:accessTier}" -o jsonc

kubectl get pvc -A --all-namespaces -o wide 

kubectl describe pv  | grep -i nfs

Expected outcome: Properly configured cluster networking, supported storage account kind for NFS, and available PVC/PV resources indicating NFS mount points. If mounts fail, check network security group rules, storage account firewall allowances, and subnet delegation. If you notice increased latency, monitor resource utilisation and consider adjusting workload placements accordingly.

1. Azure update: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS)
2. Azure Files NFS support
3. Mount Azure Files with NFS in AKS
4. Azure storage security
5. AKS networking concepts

This capability integrates SQL Server migration into the operational scope of Azure Arc, creating a streamlined migration and inventory process. For IT professionals, this is key since SQL Server modernisation often involves multiple tools and teams.

Now, you can discover, evaluate, and carry out SQL migrations through workflows native to Arc, utilising the same permissions and governance structure you already employ for infrastructure and hybrid resources.

The main benefit is consistency: discovery data aids migration planning, assessments highlight potential issues early, and rollouts can be managed through established change and approval processes utilised for other infrastructure migrations.

This operational enhancement reduces the toolset complexity and improves collaboration between infrastructure and database teams, making Azure Arc your single platform for tracking migration progress, managing runbooks, and collecting audit evidence.

Before going into production, ensure your SQL Server inventory is comprehensive, that migration hurdles are understood and addressed, and that your maintenance windows can handle expected cutover times.

Prerequisites include deploying Azure Arc agents on the source VMs, ensuring readiness with Azure Database Migration Service, and maintaining network connectivity to target Azure SQL resources.

1. Deploy Azure Arc agents to SQL Server VMs, confirming all instances indicate a healthy status with complete inventory data.
2. Run Arc-integrated assessments for SQL Server to identify compatibility issues, dependencies, and recommend migration targets.
3. Conduct a pilot migration for a non-critical workload to establish runbook patterns, measure cutover duration, and verify post-migration validation procedures.
4. Perform validation tests including connectivity, successful logins, database consistency checks, job execution, and application integration tests.
5. Expand migration in stages using documented runbooks, with checkpoints to monitor data health and application performance after every cutover.

This example confirms the health of Arc agents and completeness of SQL Server discovery. Execute these commands as part of your pre-migration checklist to catch any configuration gaps before final migration timelines are set.

az account show --output table 
az connectedmachine list --resource-group  --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  --machine-name  --query "[].{name:name,provisioningState:provisioningState}" -o table

Expected behaviour: Arc agents should display a healthy status, SQL Server instances must be fully discovered with an accurate inventory, and all necessary extensions should be provisioned successfully. If discovery seems incomplete, examine Arc agent connectivity, extension deployment, and operational status of the SQL service on source VMs. If pre-migration checks fail, verify SQL Server version compatibility and check Defender logs for any blocking issues.

1. Azure update: Expanding Azure Arc SQL Migration with SQL Server on Azure Virtual Machines
2. Azure Arc SQL Server Overview
3. Azure Arc-enabled servers
4. SQL Server on Azure Virtual Machines
5. Azure Database Migration Service

No matter the new capability this week, if they align with your operational roadmap, conduct a controlled pilot, assess the impact, and then scale with confidence. That’s how you can drive progress on modernisation while effectively managing risk.

Cheers!

Pierre Roman