SQL Server enabled by Azure Arc Overview
Table of Contents What is Azure Arc-enabled SQL Server? Connecting SQL Server to Azure Arc (4-step onboarding) Your SQL Server is Now in Azure (unified management) SQL Best Practices Assessment Monitoring and Governance Troubleshooting Guide Azure Arc Demo What You Can Learn from This Article This article walks you through the end-to-end journey of bringing external SQL Servers (on-prem, AWS, GCP, edge) under Azure management using Azure Arc. Specifically, you'll learn how to onboard SQL Server instances via the Arc agent and PowerShell script, navigate the unified Azure Portal experience for hybrid SQL estates, enable and interpret SQL Best Practices Assessments with Log Analytics, apply Azure Policy and performance monitoring across all environments, leverage Azure Hybrid Benefit for cost savings, and troubleshoot common issues like assessment upload failures, Wire Server 403 errors, and IMDS connectivity problem, with a real case study distinguishing Azure VM vs. Arc-enabled server scenarios. 1. What is Azure Arc-enabled SQL Server? Azure Arc helps you connect your SQL Server to Azure wherever it runs. Whether your SQL Server is running on-premises in your datacenter, on AWS EC2, Google Cloud, or at an edge location Azure Arc brings it under Azure management. This means you get the same governance, security, and monitoring capabilities as native Azure resources and streamline migration journey to Azure, effectively manage SQL estate at scale and strengthen security and governance posture Cloud innovation. Anywhere. SQL Server migration in Azure Arc includes an end-to-end migration journey with the following capabilities: Continuous database migration assessments with Azure SQL target recommendations and cost estimates. Seamless provisioning of Azure SQL Managed Instance as destination target, also with an option of free instance evaluation. Option to choose between two built-in migration methods: real-time database replication using Distributed Availability Groups (powered by the Managed Instance link feature), or log shipping via backup and restore (powered by Log Replay Service feature). Unified interface that eliminates the need to use multiple tools or to jump between various places in Azure portal. Microsoft Copilot is integrated to assist you at select points during the migration journey. learn more in SQL Server migration in Azure Arc – Generally Available | Microsoft Community Hub 1.1 The Problem Azure Arc Solves Organizations typically have SQL Servers scattered across multiple environments: Location Challenge Without Azure Arc On-premises datacenter Separate management tools, no unified view AWS EC2 instances Multi-cloud complexity, different monitoring Google Cloud VMs Inconsistent governance and policies Edge / Branch offices Limited visibility, manual compliance VMware / Hyper-V No cloud-native management features Azure Arc solves this by extending a single Azure control plane to ALL your SQL Servers regardless of where they physically run Azure Arc Overview Microsoft Learn: https://learn.microsoft.com/en-us/azure/azure-arc/overview Architecture Reference — Administer SQL Server with Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/azure/architecture/hybrid/azure-arc-sql-server Documentation Index — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/?view=sql-server-ver17 SQL Server migration in Azure Arc (Community Hub): https://techcommunity.microsoft.com/blog/azuresqlblog/sql-server-migration-in-azure-arc-generally-av... 2. Connecting SQL Server to Azure Arc Connecting SQL Server to Azure Arc This section shows how to onboard your SQL Server to Azure Arc. Once connected, your SQL Server appears in Azure Portal alongside your other Azure resources. 2.1 Step 1: Access Azure Arc Portal Navigation: Azure Portal → Azure Arc → Machines Figure 1: Azure Arc | Machines, Starting Point for Onboarding Description: The Azure Arc Machines blade is your entry point for connecting servers outside Azure. Click 'Onboard/Create' dropdown and select 'Onboard existing machines' to begin. The left menu shows Azure Arc capabilities: Machines, Kubernetes clusters, Data services, Licenses, etc. This is where ALL your Azure Arc-enabled servers will appear after onboarding. 2.2 Step 2: Configure Onboarding Options Select your operating system, enable SQL Server auto-discovery, and choose connectivity method: Figure 2: Onboarding Configuration, Enable SQL Server Auto-Discovery Description: Key settings: (1) Operating System select Windows or Linux, (2) SQL Server checkbox, 'Automatically connect any SQL Server instances to Azure Arc' enables auto-discovery of SQL instances on the server, (3) Connectivity method, 'Public endpoint' for direct internet access or 'Private endpoint' for VPN/ExpressRoute. The SQL Server checkbox is crucial, it installs the SQL Server extension automatically. 💡 Important: Check the 'Connect SQL Server' option! This ensures SQL Server instances are automatically discovered and connected to Azure Arc. 2.3 Step 3: Download the Onboarding Script Azure generates a customized PowerShell script containing your subscription details and configuration: Figure 3: Generated Onboarding Script, Ready to Download Description: The portal generates a PowerShell script customized for your environment. Key components: (1) Agent download from Azure CDN, (2) Installation commands, (3) Pre-configured connection parameters (subscription, resource group, location). Click 'Download' to save the script. Requirements note: Server needs HTTPS (port 443) access to Azure endpoints. 2.4 Step 4: Run the Script on Your Server Copy the script to your SQL Server and execute it in PowerShell as Administrator: Figure 4: Executing OnboardingScript.ps1 on the SQL Server Description: PowerShell console showing script execution from D:\Azure Arch directory. The script (OnboardingScript.ps1, 3214 bytes) installs the Azure Connected Machine Agent and registers the server with Azure Arc. During execution, a browser window opens for Azure authentication. After completion, the server appears in Azure Arc within minutes. What happens during onboarding: Azure Connected Machine Agent is downloaded and installed Agent establishes secure connection to Azure Server is registered as an Azure Arc resource SQL Server extension is installed (if checkbox was enabled) SQL Server instance appears in Azure Arc → SQL Server Connect Your SQL Server to Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/connect?view=sql-server-ver17 Prerequisites — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/prerequisites?view=sql-server-ver17 Manage Automatic Connection — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/manage-autodeploy?view=sql-server-ver17 3. Your SQL Server is Now Visible in the Azure Control Plane Once connected via Azure Arc, your SQL Server is projected as a resource in the Azure Portal,right alongside your native Azure SQL resources. This is the power of Azure Arc: your SQL Server remains where it runs (on-premises, in AWS, or anywhere else), but Azure's management plane now extends to it. You can govern, monitor, and secure it with the same tools you use for Azure-native resources, without migrating the workload. 3.1 Unified View in Azure Portal After onboarding, you can see your Azure Arc-enabled SQL Server through two paths: Navigation Path What You See Azure Arc → SQL Server All Azure Arc-enabled SQL instances Azure Arc → Machines The host server with extensions 3.2 Management Experience Similar to SQL Server on Azure VM The management capabilities for Azure Arc-enabled SQL Server are very similar to SQL Server on Azure VM. The screenshots below show the SQL Server on Azure VM experience Azure Arc-enabled SQL Server provides nearly identical functionality. Whether your SQL Server runs natively on an Azure VM or is connected from outside Azure via Azure Arc, you get access to a consistent management experience including: Figure 5: SQL Server Management Overview — Consistent Experience Description: This shows the management experience for SQL Server in Azure. Whether connected via Azure Arc or running on Azure VM, you see: SQL Server version and edition, VM details, License type configuration, Storage configuration, and feature status. Azure Arc-enabled SQL Server provides a nearly identical dashboard experience, extending this unified view to your on-premises and multi-cloud servers. 3.3 Azure Hybrid Benefit - Use Your Existing Licenses One of the key cost-saving advantages which is you can apply Azure Hybrid Benefit (AHB) to Azure SQL Database and Azure SQL Managed Instance, saving up to 30% or more on licensing costs by leveraging your existing Software Assurance-enabled SQL Server licenses. Note: Azure Hybrid Benefit applies to Azure SQL Database and SQL Managed Instance. For SQL Server running on-premises or in other clouds managed via Azure Arc, AHB does not apply directly. However, Arc-enabled SQL Server provides other benefits such as centralized management, Azure-integrated security, and access to Extended Security Updates (ESUs). Figure 6: Azure Hybrid Benefit Configuration Description: License configuration for SQL Server on Azure VM, showing three options: Pay As You Go, Azure Hybrid Benefit (selected), and HA/DR. With Azure Hybrid Benefit, organizations with existing SQL Server licenses and active Software Assurance can save up to 30% or more on SQL Server licensing costs running on Azure VMs (as reflected in the Azure portal configuration blade). Free SQL Server licenses for High Availability and Disaster Recovery are also available for Standard and Enterprise editions. Configure SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/manage-configuration?view=sql-server-ver1... Manage Licensing and Billing — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/manage-license-billing?view=sql-server-ve... 4. SQL Best Practices Assessment One of the most valuable features available to Azure Arc-enabled SQL Server is the Best Practices Assessment — automatically evaluating your SQL Server configuration against Microsoft's recommendations. 4.1 Prerequisites: Log Analytics Workspace Before enabling assessment, you need a Log Analytics Workspace to store the results: Figure 7: Create Log Analytics Workspace Description: Log Analytics workspace creation form. Fill in: Subscription, Resource Group, Name (green checkmark indicates valid name), and Region (choose same region as your resources). This workspace stores assessment results, performance metrics, and logs from ALL your SQL Servers both Azure Arc-enabled and Azure VMs. Figure 8: Log Analytics Workspace Ready for Use Description: Workspace overview showing: Status (Active), Pricing tier (Pay-as-you-go), and Operational issues (OK). The 'Get Started' section guides you through: (1) Connect a data source, (2) Configure monitoring solutions, (3) Monitor workspace health. This workspace becomes the central repository for all your SQL Server insights. 4.2 Enable SQL Best Practices Assessment Navigate to your SQL Server (Azure Arc-enabled or Azure VM) and enable the assessment: Figure 9: SQL Best Practices Assessment Enable Feature Description: Assessment landing page explaining the feature: evaluates indexes, deprecated features, trace flags, statistics, etc. Results are uploaded via Azure Monitor Agent (AMA). Click 'Enable SQL best practices assessments' to begin configuration. This feature is available for BOTH Azure Arc-enabled SQL Server and Azure SQL VMs. Figure 10: Assessment Configuration Select Log Analytics Workspace Description: Configuration panel requiring: (1) Enable checkbox, (2) Log Analytics workspace selection, (3) Resource group for AMA. The warning 'No Log Analytics workspace is found' appears if you haven't created one yet, see Section 4.1. Once configured, assessments run on schedule and upload results to your workspace. 4.3 Run and Review Assessment Figure 11: Run Assessment Button Description: After configuration, click 'Run assessment' to start evaluation. Assessment duration varies: 5-10 minutes for small environments, 30-60 minutes for large ones. The 'View latest successful assessment' button (disabled until first run completes) opens the results workbook. Figure 12: Assessment Results History Description: Assessment history showing multiple runs with different statuses: 'Scheduled' (pending), 'Completed' (results available), 'Failed - result expired' (data retention exceeded). Regular assessments help catch configuration drift over time. If you see 'Failed - upload failed', see the Troubleshooting section. Figure 13: Assessment Recommendations Actionable Insights Description: Best practices workbook showing three panels: (1) Recommendation Summary with severity (High, Medium) and categories (DBConfiguration, Performance, Index, Backup), (2) Recommendation Details with target and name, (3) Details panel showing selected item — example: 'Enable instant file initialization' for performance improvement. High severity items should be addressed immediately. Severity Levels: Severity Description Action Timeline 🔴 High Critical issues affecting performance or security Address immediately 🟡 Medium Important optimizations recommended Within 30 days 🟢 Low Nice-to-have improvements As time permits ℹ️ Info Informational findings Review and acknowledge Configure Best Practices Assessment — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/assess?view=sql-server-ver17 Troubleshoot Best Practices Assessment — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/troubleshoot-assessment?view=sql-server-v... Assess Migration Readiness — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/migration-assessment?view=sql-server-ver1... Log Analytics Workspace creation: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/quick-create-workspace 5. Monitoring and Governance With your SQL Servers connected to Azure (via Azure Arc or native), you gain access to Azure's full monitoring and governance capabilities. 5.1 Azure Policy Compliance Apply consistent governance policies across ALL your SQL Servers — regardless of where they run: Figure 14: Azure Policy Compliance Dashboard Description: Compliance dashboard showing: 28% overall compliance (5 of 18 resources), pie chart with Compliant (green), Exempt, and Non-compliant (red). The table lists non-compliant resources (microsoft.hybridcompute type = Azure Arc-enabled servers). Use this to ensure ALL SQL Servers, on-premises, cloud, edge meet your organization's standards. 5.2 Performance Monitoring Figure 15: Performance Monitoring Unified Dashboard Description: Performance dashboard showing: Logical Disk Performance (C: drive 30% used), CPU Utilization (1.75% average, 5.73% 95th percentile), Available Memory (3.1GB average). This same dashboard works for Azure Arc-enabled servers, giving you consistent visibility across your entire SQL Server estate. 5.3 Service Dependency Mapping Figure 16: Service Map Visualize Dependencies Description: Map view showing server FNPSVR01 with 17 processes connecting to Port 443 (7 servers) and Port 53 (1 server). Machine Summary shows FQDN, OS (Windows Server 2016), IP address. Use this to understand application dependencies before maintenance or migration available for both Azure Arc-enabled and Azure-native servers. 6. Troubleshooting Guide This section covers common issues encountered when working with Azure Arc-enabled SQL Server and Azure SQL VMs. 6.1 Common Issues Overview Issue Symptoms Azure Arc-enabled Azure VM Assessment Upload Failed Status: 'Failed - upload failed' ✅ Applies ✅ Applies Wire Server 403 Agent cannot connect ❌ N/A ✅ Applies IMDS Disabled Cannot obtain token ❌ N/A ✅ Applies Azure Arc Agent Connectivity Server not appearing ✅ Applies ❌ N/A SQL Login Failed Machine account denied ✅ Applies ✅ Applies 6.2 Real Case Study: Assessment Upload Failed on Azure VM Note: This case study is from an Azure VM (not Azure Arc-enabled). The Wire Server and IMDS issues are specific to Azure VMs. Azure Arc-enabled servers use different connectivity mechanisms. Symptoms observed: Assessment status: 'Failed - upload failed' Local data collected successfully (415 issues) Data not appearing in Log Analytics workspace Root causes identified from logs: Error 1 (ExtensionLog ): [ERROR] Customer disable the IMDS service, cannot obtain IMDS token. Error 2 (WaAppAgent.log): [WARN] GetMachineGoalState() failed: 403 (Forbidden) to 168.63.129.16 Resolution for Azure VMs Fix Wire Server (168.63.129.16) connectivity: # Test connectivity Test-NetConnection -ComputerName 168.63.129.16 -Port 80 # Add route if missing route add 168.63.129.16 mask 255.255.255.255 <gateway> -p # Add firewall rule if needed New-NetFirewallRule -DisplayName "Allow Azure Wire Server" -Direction Outbound -RemoteAddress 168.63.129.16 -Action Allow Fix IMDS (169.254.169.254) connectivity: # Test IMDS Invoke-RestMethod -Uri "http://169.254.169.254/metadata/instance?api-version=2021-02-01" -Headers @{Metadata="true"} # Add firewall rule if blocked New-NetFirewallRule -DisplayName "Allow Azure IMDS" -Direction Outbound -RemoteAddress 169.254.169.254 -Action Allow Test Azure Arc agent connectivity: # Check Arc agent status & "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" show # Test connectivity to Azure endpoints & "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" check 6.3 Azure Arc-enabled SQL Server Connectivity Issues For Azure Arc-enabled servers (not Azure VMs), connectivity issues are different: Required Azure endpoints for Azure Arc agent: Endpoint Port Purpose management.azure.com 443 Azure Resource Manager login.microsoftonline.com 443 Azure AD authentication *.his.arc.azure.com 443 Azure Arc Hybrid Identity *.guestconfiguration.azure.com 443 Guest configuration Troubleshoot Best Practices Assessment Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/troubleshoot-assessment?view=sql-server-v... What is IP Address 168.63.129.16 (Wire Server) Microsoft Learn: https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16 Azure Instance Metadata Service (IMDS) Microsoft Learn: https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service Troubleshoot IMDS Connection Issues on Windows VMs Microsoft Learn: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/windows-vm-imds-connec... Troubleshoot Azure Windows VM Agent Issues Microsoft Learn: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/windows-azure-guest-ag... 7. Troubleshooting Guide Demo Deck: Azure Arc for Windows Server and SQL Server More Additional Resources : Learn more about the new migration capability in Azure Arc on Microsoft Learn. Onboard your SQL Server to Azure Arc today. Learn more about continuous migration assessment from SQL Server enabled by Azure Arc. Download resources on github.com/microsoft/sql-server-samples
From fragmented sites to consistent governance: Azure Arc patterns for adaptive cloud strategy.
In Manufacturing companies, hybrid architectures aren’t transitional—they’re persistent. Most large manufacturers operate across remote plants, branch sites, private datacenters, and Azure. The main challenge manufacturers face isn’t adopting cloud services, it is preventing long‑term operational fragmentation: multiple teams, multiple tools, inconsistent security controls, and uneven governance as the estate grows. When manufacturing IT grows organically, systems end up scattered across factories, edge, and cloud—creating fragmentation instead of flow. Azure Arc addresses this as an architectural control‑plane pattern: it extends Azure management to infrastructure and Kubernetes outside Azure by projecting them into Azure Resource Manager (ARM) so they can be governed using Azure-native primitives such as policy, RBAC, and monitoring. This article describes three architecture patterns that consistently emerge in manufacturing and edge scenarios. Each pattern addresses a distinct set of constraints—ranging from centralized governance across hybrid estates, to plant‑adjacent platforms, to fully disconnected environments—and illustrates how Azure services can be composed to support these realities in a scalable, well‑governed way. Typical manufacturing environments must contend with some or many of the following components: Latency & determinism: plant-floor systems often require local execution Distributed footprint: dozens/hundreds of sites with varying maturity Connectivity variability: some sites are intermittently connected Regulatory & data constraints: some workloads must remain on premises Cloud: Native cloud applications including the AI based research applications, SAP systems, etc. As a result, the estate becomes a mix of Azure + non‑Azure infrastructure. The failure mode isn’t performance—it’s inconsistent operations: different patching methods, different monitoring stacks, and uneven security baselines. Azure Arc is positioned specifically to create unity across that operational model by bringing hybrid resources into the Azure control plane. A helpful way to think about Arc in manufacturing scenario is to separate the control plane and the data plane: Arc enables a centralized control plane by projecting resources, like the ones below, into ARM: Azure Resource Manager (resource inventory, tags, RBAC, Policy) Security posture & compliance (Defender for Cloud, policy initiatives) Observability and operations workflows (Azure Monitor, Update Manager, etc.) Whereas the data plane remains at distributed locations meaning: Workload execution remains at plants, private DCs, or edge sites Kubernetes API endpoints, runtime traffic, OT systems remain local This separation is an architectural lever allowing organizations to standardize governance without forcing workload relocation. A high-level design decision matrix Constraint Recommended starting pattern Why Many sites + inconsistent tooling Arc as distributed control plane Standardizes governance and inventory via ARM projection Plant workloads require local platform Azure Local + Arc Uses Azure Local baseline + Arc integration for operations Connectivity cannot be assumed Disconnected/intermittent design Forces control-plane boundary design + local autonomy Pattern 1 — Azure Arc as the distributed control plane (for VM, SQL severs+ Kubernetes) When this pattern fits Use this pattern when: You need consistent governance across plants, datacenters, and multicloud You can maintain at least periodic connectivity for control-plane sync You want Azure policy/security/monitoring to apply uniformly Architecture intent Azure Arc projects existing bare metal, VM, and Kubernetes infrastructure resources into Azure to handle operations with Azure management and security tools. Azure Arc simplifies governance and management by delivering a consistent multicloud and on-premises management platform experience for Azure services. Once projected, you can operate hybrid resources using Azure-native constructs (inventory, compliance reporting, policy scope) and apply standardized guardrails. From an architectural standpoint, Azure Arc establishes a centralized control plane in Azure (ARM, RBAC, Policy, Resource Graph) and decentralized data plane remaining at plants, datacenters, or edge sites. This separation enables organizations to apply management‑group–scoped policies, standardized tagging, and Defender for Cloud controls consistently across environments, while preserving local execution and latency characteristics required by manufacturing workloads. Why this pattern matters: It moves organizations from managing individual sites to governing the entire estate as one. It minimizes operational drift as environments expand across plants and edge locations. Centralized control simplifies enforcement of standards without slowing local operations. The pattern creates predictability at scale in highly distributed environments. It establishes a stable foundation for future modernization initiatives. Pattern 2 — Azure Local + Azure Arc (plant-adjacent platform pattern) When this pattern fits Use this pattern when: Workloads must run on premises for latency, sovereignty, or operational control You want cloud-consistent operations without creating a separate tooling island You need a standardized platform for virtualized + containerized workloads at sites You need the local AI inferencing where data needs to be processed at the source/plant site Architecture intent Azure Local Microsoft’s distributed infrastructure solution that extends Azure capabilities to customer-owned environments. It facilitates the local deployment of both modern and legacy applications across distributed or sovereign locations. Azure Local accelerates cloud and AI innovation by seamlessly delivering new applications, workloads, and services from cloud to edge, using Azure Arc as the unifying control plane. From an architectural perspective, Azure Local serves as the local data plane for applications—supporting general‑purpose virtual machines, managed Kubernetes (AKS), and selected Azure services—while Azure Arc extends the Azure control plane to that environment for inventory, policy, monitoring, and security integration. This separation allows workloads to run close to manufacturing systems without creating a parallel or disconnected operational model. Azure Local supports a broad spectrum of workload types on the same platform foundation, including: Traditional line‑of‑business applications on virtual machines Modern containerized workloads using AKS on Azure Local Azure‑consistent platform services that can be deployed locally, such as Azure Virtual Desktop and SQL Managed Instance GPU‑accelerated workloads for AI inferencing and computer vision scenarios Why this pattern matters: Without a platform like Azure Local integrated through Azure Arc, on‑premises manufacturing workloads tend to evolve into bespoke environments with inconsistent security, monitoring, and lifecycle management—making long‑term scale and governance increasingly difficult. Pattern 3 — Disconnected edge workloads (connectivity-constrained design) When this pattern fits Use this pattern when: Sites cannot assume continuous connectivity Local autonomy is required for safety or production continuity You still want centralized governance when connected Architecture intent In manufacturing and edge scenarios, some environments must operate without continuous internet connectivity due to regulatory constraints, physical isolation, or operational risk tolerance. In these cases, architectures must assume that cloud control‑plane access is intermittent or unavailable, while local execution must continue without disruption. Disconnected architectures shift the primary design concern from availability of services to autonomy of execution. This pattern applies to environments that are fully offline, intermittently connected, or explicitly restricted from sending data to public cloud endpoints. Azure supports this model through Disconnected-containers, where containerized services are deployed and operated fully offline. Once provisioned, these containers run entirely on local infrastructure with no runtime dependency on Azure endpoints, enabling uninterrupted execution even during extended disconnection periods. Disconnected containers are offered through commitment tier pricing, each offering a discounted rate compared to the Standard pricing model. Learn more about pricing here: Plan and Manage Costs - Microsoft Foundry | Microsoft Learn Before attempting to run a Docker container in an offline environment, make sure you know the steps to successfully download and use the container. For example: Host computer requirements and recommendations. The Docker pull command you use to download the container. How to validate that a container is running. How to send queries to the container's endpoint once it's running. Why this pattern matters: This pattern matters because not all environments can rely on continuous connectivity. It enables critical workloads to operate independently at the edge while remaining aligned to central governance when connectivity is available. The pattern prioritizes local autonomy without sacrificing architectural discipline. It reduces operational risk in constrained or disconnected sites. This approach ensures resilience and continuity in environments where connectivity cannot be assumed. Manufacturing IT will remain distributed by design. The risk is not hybrid complexity, but fragmented operations. By centralizing the control plane while keeping execution local, Arc enables consistent security, compliance, and operations across cloud, datacenter, and edge.Announcing Private Preview: Deploy Ansible Playbooks using Azure Policy via Machine Configuration
Azure Arc is on a mission to unify security, compliance, and management for Windows and Linux machines—anywhere. By extending Azure’s control plane beyond the cloud, Azure Arc enables organizations to unify governance, compliance, security and management of servers across on‑premises, edge, and multicloud environments using a consistent set of Azure tools and policies. Building on this mission, we’re excited to announce the private preview of deploying Ansible playbooks through Azure Policy using Machine Configuration, bringing Ansible‑driven automation into Azure Arc’s policy‑based governance model for Azure and Arc‑enabled Linux machines. This new capability enables you to orchestrate Ansible playbook execution directly from Azure Policy (via Machine Configuration) without requiring an Ansible control node, while benefiting from built‑in compliance reporting and remediation. Why this matters As organizations manage increasingly diverse server estates, they often rely on different tools for Windows and Linux, cloud, on-premises, or at the edge—creating fragmented security, compliance, and operational workflows. Many organizations rely on Ansible for OS configuration and application setup, but struggle with: Enforcing consistent configuration across distributed environments Detecting and correcting drift over time Integrating Ansible automation with centralized governance and compliance workflows With this private preview, Azure Policy becomes the single control plane for applying and monitoring Ansible‑based configuration, bringing Linux automation into the same governance model already used for Windows. Configuration is treated as policy—declarative, auditable, and continuously enforced—with compliance results surfaced in familiar Azure dashboards. What’s included in the private preview In this preview, you can: Use Azure Policy to trigger Ansible playbook execution on Azure and Azure Arc–enabled Linux machines Execute playbooks locally on each target machine, triggered by policy. Enable drift detection and automatic remediation by default View playbook execution status and compliance results directly in the Azure Policy compliance dashboard, alongside your other policies This provides a unified security, compliance and management experience across Windows and Linux machines—whether they’re running in Azure or connected through Azure Arc—while using your existing Ansible investments. Join the private preview If you’re interested in helping shape the future of Ansible‑based configuration management in Azure Arc, we’d love to partner with you. We’re especially interested in hearing your stories around usability, compliance reporting, and real‑world operational workflows. 👉 Sign up for the private preview and we'll reach out to you. We’ll continue investing in deeper Linux parity, broader scenarios, and tighter integration across Azure Arc’s security, governance and compliance experiences. We look forward to enhancing your unified Azure Arc experience for deploying, governing, and remediating configuration with Ansible—bringing consistent security, compliance, and management to Windows and Linux machines not only in Azure, but also across on‑premises and other public clouds.Simplify Azure Arc Server Onboarding with Ansible and the New Onboarding Role
If you’re already using Ansible to manage your infrastructure, there’s now a simpler—and more secure—way to bring machines under Azure Arc management. We’ve introduced a new Azure Arc onboarding role designed specifically for automated scenarios like Ansible playbooks. This role follows the principle of least privilege, giving your automation exactly what it needs to onboard servers—nothing more. A better way to onboard at scale Many customers want to standardize Azure Arc onboarding across hybrid and multicloud environments, but run into common challenges: Over‑privileged service principals Manual steps that don’t scale Inconsistent onboarding across environments By combining Ansible with the Azure Arc onboarding role, you can: Automate server onboarding end‑to‑end Reduce permissions risk with a purpose‑built role Scale confidently across thousands of machines Integrate Arc onboarding into existing Ansible workflows Built for automation, designed for security The new onboarding role removes the need to assign broader Azure roles just to connect servers to Azure Arc. Instead, your Ansible automation can authenticate using a tightly scoped identity that’s purpose‑built for Arc onboarding—making security teams happier without slowing down operations. Whether you’re modernizing existing datacenters or managing servers across multiple clouds, this new approach makes Azure Arc onboarding simpler, safer, and repeatable. Get started in minutes Our Microsoft Learn documentation provides guidance to help you get started quickly: Connect machines to Azure Arc at scale with Ansible Check out the Arc onboarding role, part of the Azure collection in Ansible Galaxy: Ansible Galaxy - azure.azcollection - Arc onboarding role Anything else you’d like to see with Azure Arc + Linux? Drop us a comment!Run the latest Azure Arc agent with Automatic Agent Upgrade (Public Preview)
Customers managing large fleets of Azure Arc servers need a scalable way to ensure the Azure Arc agent stays up to date without manual intervention. Per server configuration does not scale, and gaps in upgrade coverage can lead to operational drift, missed features, and delayed security updates. To address this, we’re introducing two new options to help customers enable Automatic Agent Upgrade at scale: applied as a built-in Azure Policy and a new onboarding CLI flag. The built-in policy makes it easy to check whether Automatic Agent Upgrade is enabled across a given scope and automatically remediates servers that are not compliant. For servers being newly onboarded, customers can enable the feature at onboarding by adding the --enable-automatic-upgrade flag to the azcmagent connect command, ensuring the agent is configured correctly from the start. What is Automatic Agent Upgrade? Automatic Agent Upgrade is a feature, in public preview, that automatically keeps the Azure Connected Machine agent (Arc agent) up to date. Updates are managed by Microsoft, so once enabled, customers no longer need to manually manage agent upgrades. By always running the latest agent version, customers receive all the newest capabilities, security updates, and bug fixes as soon as they’re released. Learn more: What's new with Azure Connected Machine agent - Azure Arc | Microsoft Learn. Getting Started Apply automatic agent upgrade policy Navigate to the ‘Policy’ blade in the Azure Portal Navigate to the ‘Compliance’ section and click ‘Assign Policy’ Fill out the required sections Scope: Subscription and resource group (optional) that policy will apply to Policy definition: Configure Azure Arc-enabled Servers to enable automatic upgrades Navigate to the ‘Remediation’ tab and check the box next to ‘Create a remediation task’ Navigate to the ‘Review + create’ tab and press ‘Create’. The Policy has been successfully applied to the scope. For more information on this process, please visit this article Quickstart: Create policy assignment using Azure portal - Azure Policy | Microsoft Learn. Apply automatic agent upgrade CLI Flag Adding the following flag enables automatic agent upgrade during onboarding --enable-automatic-upgrade While this flag can be used on a single server, it can also be applied at scale using one of the existing Azure Arc at scale onboarding methods and adding the flag Connect hybrid machines to Azure at scale - Azure Arc | Microsoft Learn. Here is an at scale onboarding sample using a basic script. azcmagent connect --resource-group {rg} --location {location} --subscription-id {subid} --service-principal-id {service principal id} --service-principal-secret {service principal secret} --tenant-id {tenant id} --enable-automatic-upgrade To get started with this feature or learn more, please refer to this article Manage and maintain the Azure Connected Machine agent - Azure Arc | Microsoft Learn.
Building Microsoft’s Sovereign AI on Azure Local with NVIDIA RTX PRO and Next Gen NVIDIA Rubin
This blog explores how Azure Local, in partnership with NVIDIA, enables governments and regulated industries to build and operate Sovereign AI within their own trusted boundaries. From enterprise AI acceleration available today with NVIDIA RTX PRO™ Blackwell GPUs to a forward‑looking preview of next‑generation NVIDIA Rubin support, Azure Local provides a consistent platform to run advanced AI workloads—connected or fully disconnected—without sacrificing control, compliance, or governance. Together with Foundry Local, AKS on Azure Local, and Azure Arc, customers can bring AI closer to sensitive data and evolve their Sovereign Private Cloud strategies over time with confidence.
Accelerating SaaS success with reference code for Marketplace fulfillment API integration
Boost your growth and reach more customers by replicating your AWS app to Azure to sell through Microsoft Marketplace. This guide will introduce the essential building blocks required for a smooth replication experience and highlight how Marketplace Fulfillment APIs streamline and automate critical post‑purchase workflows. Future posts in this series will explore each topic in more depth to help streamline your multicloud strategy. This post is part of a series on replicating apps from AWS to Azure. View all posts in this series. As a Software Development Company, expanding your Marketplace offer’s reach by replicating your app from AWS to publish to Microsoft Marketplace opens the door to scaling your solution across a global customer base. With millions of organizations using Azure, this ecosystem provides a powerful commercialization channel that enhances discoverability, drives conversions, and delivers a unified, cloud‑native buying experience. You can also join ISV Success to get access to over $126K USD in cloud credits, AI services, developer tools, and 1:1 technical consults to help you replicate your app and publish to Azure Marketplace. To help Software Companies enter the Marketplace successfully, it’s important to understand the operational components that shape the customer experience. One of the most critical components is the Fulfillment API ecosystem, which manages everything from subscription activation to entitlement updates and provisioning workflows. This guide introduces the Fulfillment API model, explains why it is essential for Software Companies preparing or optimizing their SaaS offers for the Marketplace, and directs you to a curated set of resources that provide actionable, hands‑on guidance for implementing these capabilities. Access the resources now or continue reading to learn their importance in creating a successful transactable offer that you can sell through Marketplace. Why fulfillment APIs matter for Marketplace success To sell through the Marketplace smoothly and take advantage of its 6M monthly active shoppers across 141 geographies, you need to integrate fulfillment APIs. Publishing a SaaS offer to the Marketplace is only the first step. What happens after a customer clicks “Subscribe” determines how quickly they can begin using your product—and how seamless their experience will be throughout the lifecycle of their subscription. Fulfillment APIs act as the bridge between the Marketplace and your application. They automatically notify your system when a customer starts, updates, suspends, or ends a subscription. Instead of relying on manual steps or custom internal workflows, the Marketplace standardizes these interactions to ensure predictability and consistency. For Software Companies onboarding to the Marketplace, Fulfillment API integration delivers significant benefits: Immediate and automated customer activation When a customer completes a transaction, the Fulfillment APIs notify your application so you can begin provisioning instantly. This eliminates delays, reduces onboarding friction, and ensures a smooth first‑time user experience. Consistent entitlement management Fulfillment APIs help you maintain accurate entitlement records automatically. Plan changes, cancellations, or updates to the number of users included in a subscription are sent to your application as lifecycle events—ensuring your system always reflects the customer’s current state. Operational efficiency and reduced overhead By relying on a defined, event‑driven model, your teams avoid creating and maintaining custom logic for every lifecycle scenario. This allows you to focus engineering resources on your product instead of transaction plumbing. Scalability across regions and customer segments As your Marketplace presence grows, Fulfillment API integration ensures your operational foundation remains stable, predictable, and ready for increased transaction volume. Support for private offers and custom commercial models The same event‑driven lifecycle applies whether a customer purchases publicly or under a custom private offer—creating a unified, dependable experience. Introducing the fulfillment API resource collection To help Software Companies implement these capabilities quickly, Microsoft provides a comprehensive Fulfillment API resource collection. This curated set brings together conceptual guidance, architectural patterns, learning materials, and hands‑on resources, including the open‑source SaaS Accelerator. The collection gives you everything you need to understand, design, and implement the subscription lifecycle within your own application. Some of the topics covered include: 1. End‑to‑End subscription lifecycle overview A detailed explanation of how Marketplace transactions work, what events your application should expect, and how to handle activation, provisioning, suspension, and cancellation flows. 2. Reference code implementation The SaaS Accelerator demonstrates the full Fulfillment API workflow in a working customizable end‑to‑end solution. Software Companies can use it as a learning tool or a foundational starting point. 3. Architecture and design guidance Clear architectural diagrams and recommendations illustrate best practices for handling webhook callbacks, securing API endpoints, managing tokens, and scaling your implementation. 4. How to build your landing page Guidance on creating a transactable landing page that captures customer information, initiates provisioning, and provides a clear next step for new subscribers. 5. Webhook and callback handling Step‑by‑step patterns for receiving, validating, and processing lifecycle events sent from the Marketplace. 6. Pricing plans, seat management, and entitlements Best practices for aligning your application’s internal logic with the Marketplace’s commercial and operational model. These resources are designed for teams at any stage—whether you’re preparing your first listing or modernizing an existing offer to align with Marketplace standards. Laying a strong foundation for marketplace scale Introducing your SaaS offer to the Marketplace is a significant milestone, but long‑term success requires dependable operational flows and high‑quality customer experiences. Fulfillment API integration is the backbone of these experiences, ensuring that your application responds reliably and consistently to customer actions. By leveraging the curated Fulfillment API collection and the open‑source accelerator, Software Companies can reduce time to market, eliminate guesswork, and build a strong integration that scales as customer adoption grows. Get started with the Marketplace fulfullment API resource collectionMigrating your AWS offer to Microsoft Marketplace - AWS to Azure service comparisons
As an Independent Software Vendor (ISV), expanding your Marketplace offer's reach beyond AWS Marketplace by replicating to Microsoft Marketplace offers exciting opportunities to grow your customer base. With millions of customers across a global network of businesses and industries, Azure presents a thriving platform to enhance your app’s visibility and functionality. This post is part of a series on replicating apps from AWS to Azure. View all posts in this series. Boost your growth and access more customers by replicating your AWS app to Azure and selling through Microsoft Marketplace. This guide will compare commonly used AWS and Azure components, highlighting differences, to help you replicate your app quickly and easily to prepare it for publishing on Microsoft Marketplace. Future posts will dive deeper into each component area. To ensure a seamless app replication, start by reviewing the marketplace listing requirements. Understanding the key differences between AWS and Azure will help you transition and optimize performance on Azure while benefiting from its unique advantages. This guide will outline these differences, highlight similar services, and offer steps for a seamless replication or migration. You can also join ISV Success to get access to over $126K USD in cloud credits, AI services, developer tools, and 1:1 technical consults to help you replicate your app and publish to Marketplace. The benefits of replicating or migrating to Microsoft Marketplace Migrating to Marketplace unlocks a wealth of opportunities for ISVs. The Azure ecosystem offers several advantages, including: Global reach: Azure’s vast global network of data centers ensures high availability and low-latency access to your application for customers worldwide. Cost efficiency: Azure’s flexible pricing models and cost management tools allow ISVs to optimize their cloud spending. Scalability: With Azure’s powerful compute and storage options, you can scale your application effortlessly to accommodate growing demand. Security and compliance: Azure’s comprehensive security tools and certifications help you meet industry-specific compliance standards, ensuring that your application is secure and trusted. Meet where your customers are: Deploy into customer subscriptions, making your solution more integrated to customer workload. AWS vs. Azure AWS and Azure are the top cloud platforms with diverse services for developers and businesses. Below, we will highlight key areas where AWS and Azure differ—and how to leverage Azure services—when moving your Marketplace offer from AWS to Microsoft Marketplace. Microsoft Marketplace capabilities In Azure, ISVs can leverage metered billing to charge customers based on actual usage, similar to AWS's pay-as-you-go model. This flexible pricing model is ideal for SaaS solutions. Partner Center offers tools for setting pricing models, tracking usage, and adjusting billing. It also provides anomaly detection to help partners identify unexpected usage and ensure transparent billing. When creating SaaS offers in Marketplace, ISVs can define plans with various pricing strategies, such as usage-based or flat-rate billing. These plans, or SKUs, can be customized through free trials, BYOL (Bring Your Own License), or vCPU-based pricing for virtual machines. Both Azure and AWS allow flexible, metered billing based on usage. Azure also provides the ability to set customer discounts or negotiated pricing. Using Partner Center, you can configure and manage these offerings, providing flexibility for customers and partners to scale as needed. Like AWS Control Tower, Azure Lighthouse enables service providers to manage multiple customer Azure environments securely and at scale, offering enhanced visibility, control, and automation. For usage-based monthly billing, you can choose from predefined or custom pricing options (using metered billing APIs). Predefined options like per core, per node, or per pod let Microsoft bill customers based on hourly usage, billing them monthly. Learn more about usage-based pricing here: Setting Plan Pricing. Mapping AWS services to Azure services Your Marketplace offer may use multiple AWS services, and you can build the same offer using Azure services. However, this requires careful mapping to ensure your application functions seamlessly in the Azure environment. Here’s a quick overview of how popular AWS services map to Azure:: Networking: AWS VPC → Azure Virtual Networks (VNets) Compute Services: AWS EC2 → Azure Virtual Machines (VMs), Azure App Services (for web apps) Storage: Amazon S3 → Azure Blob Storage, Azure Data Lake Storage (for big data) Identity Management: AWS IAM → Entra ID Containers: EKS and Elastic Beanstalk → AKS and Azure App Services Serverless: AWS Lambda → Azure Functions Databases: Amazon RDS → Azure SQL Database, Azure Cosmos DB (for NoSQL) Azure for AWS professionals provides you with a more comprehensive mapping of different services. Let's take a deeper look into each of these areas. Cloud architecture and networking One of the primary differences between AWS and Azure lies in their cloud architecture and networking models. AWS uses Virtual Private Clouds (VPCs) to create isolated networks, while Azure employs Virtual Networks (VNets). Both services perform similar functions, but they have different terminologies and setups. For instance, in Azure, you'll be working with VNet Peering, Network Security Groups (NSGs), and Azure VPNs for secure networking. The goal is to map your AWS VPC setup to Azure VNets with ease. AWS needs a Nat Gateway for egress access whereas Azure does not need a Nat Gateway for default egress. AWS Subnets are pinned to Availability Zones (AZs) whereas Azure Subnets span across the AZs. Compute services: EC2 vs. Virtual Machines (VMs) AWS EC2 instances are one of the most widely used compute services, allowing you to run applications on virtual servers. In Azure, the equivalent service is Azure Virtual Machines (VMs). While both offer scalable compute resources, the key differences are in the range of VM sizes, configurations, and the management interface. When migrating from AWS EC2 to Azure VMs, it's important to assess the appropriate Azure VM sizes and configurations that match the performance of your EC2 instances. Additionally, Azure VMs support Azure Resource Manager (ARM) templates, which provide more automation for resource management. For those who have utilized EC2's Auto Scaling feature, Azure provides similar functionality through Azure Scale Sets. Storage: S3 vs. Blob Storage For object storage, AWS uses Amazon S3, while Azure uses Azure Blob Storage. Both services serve the same purpose — storing large amounts of unstructured data — but the underlying configurations, security features, and cost structures differ. While migrating from S3 to Blob Storage, it’s important to review your storage needs and adjust your application accordingly. Azure Blob Storage offers Cool and Archive tiers, which can be a great way to optimize storage costs for infrequently accessed data, and Azure's data redundancy options ensure high availability and durability. The Azure Storage Explorer tool also makes it easier for ISVs to manage their data after migration. Identity and Access Management (IAM) & billing: IAM vs. Entra ID IAM services on AWS and Azure differ in how they manage roles and permissions. AWS uses IAM for users, roles, and policies, while Azure uses Entra ID for IAM across cloud services. AWS organizes accounts through AWS Organizations, with IAM used for role-based access control (RBAC) and policies for service access. Azure’s structure involves Subscriptions and Management Groups, with Entra ID managing identity and access. Azure uses RBAC to assign roles at various levels (Subscription, Resource Group, Resource) and Azure Policies for governance and compliance. Azure Entra ID integrates with Microsoft services, like Office 365, SharePoint, and Teams, supporting identity federation, multi-factor authentication, and RBAC for granular permissions. It enhances governance and security across platforms. Azure handles billing management via subscriptions providing access to resources and can be reassigned to new owners. It offers three classic subscription administrator roles for resource access and management for billing and resource access. Container management: Elastic Beanstalk vs. Azure App Services and EKS vs. AKS For containerized applications, AWS offers Elastic Beanstalk for easy application deployment and management. Azure’s equivalent services include Azure App Services for simple web application hosting and Azure Kubernetes Service (AKS) for container orchestration. While Azure App Services is more suitable for traditional web applications, AKS provides a robust and scalable solution for microservices and containerized applications, similar to AWS’s Elastic Kubernetes Service (EKS). ISVs who are accustomed to Elastic Beanstalk for deploying containerized applications will find Azure App Services or AKS a seamless alternative, with Azure offering rich integrations with DevOps pipelines, CI/CD workflows, and container registries. Serverless: AWS Lambda vs. Azure Functions Both AWS and Azure support serverless computing, which allows developers to run code without managing servers. AWS offers Lambda, while Azure offers Azure Functions. Both services allow you to trigger code in response to events, such as file uploads or API calls. The key difference is that Azure Functions integrates deeply with other Azure services, such as Azure Logic Apps and Azure Event Grid. If your application leverages AWS Lambda, you will find that Azure Functions can serve as an excellent equivalent. Azure also provides Durable Functions, which extend Azure Functions for stateful workflows. Migrating from AWS Lambda to Azure Functions typically requires mapping your event-driven functions and configuring their triggers in the Azure ecosystem. Databases: RDS vs. Azure SQL and Cosmos DB When it comes to databases, AWS offers Amazon RDS for relational databases, and Amazon DynamoDB for NoSQL. Azure provides several alternatives, including Azure SQL Database for relational storage and Azure Cosmos DB for NoSQL storage. Both platforms support database scalability, automated backups, and high availability. If you are using Amazon RDS with services like MySQL or PostgreSQL, you can migrate to Azure Database for MySQL or Azure Database for PostgreSQL. Similarly, if you are using AWS DynamoDB, Azure’s Cosmos DB offers a global, scalable NoSQL database with low-latency access. Messaging: AWS SQS vs. Azure Service Bus Messaging services are crucial when your application handles high-throughput, asynchronous communication between different components. AWS offers Simple Queue Service (SQS) for messaging and SNS for pub/sub notifications while Azure offers Azure Service Bus and Azure Event Grid. Azure Service Bus provides similar functionality to SQS but offers additional capabilities like advanced message routing, dead-lettering, and sessions for handling ordered messages. If your application relies on a queuing mechanism for inter-service communication, you’ll want to map AWS SQS to Azure Service Bus. For event-driven architectures, Azure Event Grid can connect different services and trigger actions across Azure services. Security: Protecting your application on Azure When migrating from AWS to Azure, security is paramount. Both platforms offer strong frameworks to protect data, apps, and infrastructure. Azure provides a suite of integrated security services to maintain high security while enabling cloud scalability. AWS offers AWS Shield and WAF for DDoS and web application firewalls, while Azure offers Azure DDoS Protection and Azure Firewall for similar threat prevention. Azure Security Center monitors your security posture, and Azure Sentinel provides cloud-native SIEM (Security Information and Event Management) for threat detection and response. Microsoft Defender for Identity and Azure Entra ID Identity Protection integrate with Entra ID, ensuring your app security is tightly linked to user identity and governance. Compliance: Meeting regulatory standards on Azure Ensuring compliance with industry standards and regulations is crucial for many ISVs. Azure provides a robust compliance framework that aligns with global standards to meet the most stringent requirements. Whether your application deals with sensitive data or operates in highly regulated industries, Azure’s comprehensive compliance offerings can help you achieve the necessary certifications. Azure complies with key standards such as: GDPR HIPAA SOC 1, 2, and 3 ISO 27001 and other ISO standards FedRAMP Azure provides tools like Azure Policy for governance and Azure Blueprints for complex regulatory requirements. It offers a similar set of compliance certifications to AWS, with a stronger integration into Microsoft enterprise tools, easing compliance for businesses in regulated sectors. For apps handling sensitive data, use Azure Security and Compliance Blueprint to ensure regulatory adherence. Azure’s Compliance Manager helps track and manage compliance, simplifying the process of meeting industry standards. Key resources SaaS Workloads - Microsoft Azure Well-Architected Framework | Microsoft Learn Metered billing for SaaS offers in Partner Center Create plans for a SaaS offer in Azure Marketplace Metered billing with Azure Managed Applications Set plan pricing and availability for an Azure Container offer in Microsoft commercial marketplace - Marketplace publisher Configure pricing and availability for a virtual machine offer in Partner Center - Marketplace publisher Overview - CSP marketplace - Partner Center Azure for AWS professionals - Azure Architecture Center Azure networking documentation Microsoft Entra ID documentation - Microsoft Entra ID Azure security documentation Azure compliance documentation Azure Storage Documentation Hub Microsoft Azure container services documentation Azure serverless - Azure Logic Apps Migration examples Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV Success Maximize your momentum with step-by-step guidance to publish and grow your app with App AdvisorMigrating your AWS offer to Microsoft Marketplace - AWS to Azure security model comparison
As an Independent Software Vendor (ISV), extending your Marketplace presence beyond AWS Marketplace by also offering on Microsoft Marketplace can unlock new opportunities to expand your customer base. With Azure's extensive network and diverse user base, it provides a vibrant platform to increase your application's visibility and capabilities. This post is part of a series on replicating apps from AWS to Azure. View all posts in this series. To streamline your app replication, understanding how AWS and Azure treat Identity and Access Management, data protection, threat detection and monitoring, compliance and certifications, and network security can help you map and adjust the security components of your app more quickly as you replicate, and ensure your app and your customer's security are protected. You can also join ISV Success to get access to over $126K USD in cloud credits, AI services, developer tools, and 1:1 technical consults to help you replicate your app and publish to Marketplace. Overview of cloud security models When moving your app from AWS Marketplace to Microsoft Marketplace, it's important to understand the key differences between AWS and Azure security models to ensure a smooth transition. Here are the main points you should keep in mind: AWS: In AWS’s shared responsibility model, AWS handles infrastructure security (like physical security and network controls), while you are responsible for securing your applications, data, and access controls. This includes managing network security, identity and access management (IAM), and data encryption. AWS uses services like Amazon GuardDuty and Amazon Inspector for threat protection and threat detection and vulnerability monitoring. Azure: Azure’s shared responsibility model focuses on compliance and regulatory requirements. It offers integrated services to secure data, applications, and infrastructure, simplifying compliance. Azure natively integrates with third-party security tools like Palo Alto Networks, Check Point, CrowdStrike and McAfee via services like Microsoft Defender for Cloud and Microsoft Sentinel for centralized security and threat detection. Microsoft Entra ID works with third-party identity providers such as Okta and Ping Identity for flexible authentication and access management without being locked into a single vendor. The Marketplace also offers pre-configured security solutions, simplifying deployment and integration of security tools while maintaining flexibility. Understanding these differences can significantly ease the process and enhance the security of your cloud solutions, setting you up for success on both platforms. Figure 1https://learn.microsoft.com/en-us/azure/architecture/guide/security/security-start-here Identity and Access Management (IAM) IAM ensures that only authorized users and services can access cloud resources. AWS and Azure differ in how they manage user identities and permissions. Understanding these differences will help you map your AWS app to Azure by leveraging Azure’s IAM services. AWS: AWS uses IAM to centrally manage user identities and access permissions, with roles and policies defined in JSON for granular control. It also offers AWS Cognito for user identity management in custom applications and AWS SSO to simplify authentication across AWS accounts. While AWS IAM provides flexibility, it requires more manual configuration for complex use cases. Azure: Azure uses Microsoft Entra ID (formerly Azure AD), a cloud-based identity and access management service that provides more integrated security, especially for enterprise environments. It supports Role-Based Access Control (RBAC), which simplifies permission management by assigning predefined roles to users or groups, and integrates seamlessly with Microsoft products like Office 365, Microsoft Entra ID Connect, and third-party applications. It also offers advanced features like multi-factor authentication (MFA) and conditional access policies for context-based authentication. For ISVs migrating from AWS to Azure, Entra ID offers a more unified, scalable solution, particularly for hybrid environments and organizations with existing Microsoft infrastructure. Feature AWS IAM Azure Entra ID Core Access Model RBAC RBAC Default Access Implicit Deny Implicit Deny Policy Granularity Fine-grained IAM policies Granular access through Azure RBAC MFA Included for basic features Basic MFA included; advanced with Microsoft Entra ID Premium Conditional Access Limited support Advanced with Microsoft Entra ID Premium Audit Logging CloudTrail, CloudWatch Sign-In Logs, Azure Monitor Cross-Account Access IAM roles between AWS accounts Microsoft Entra ID B2B across tenants Federation Supports external identity providers Microsoft Entra External ID B2B/B2C Role Delegation Delegation within/across accounts Delegation across subscriptions Service Role IAM roles for services Managed identities for services Custom Roles Custom IAM policies Custom Azure RBAC roles Access to Resources Fine-grained resource access Resource, subscription, management-group level Compliance AWS Artifact Azure Compliance Manager Risk Detection AWS GuardDuty Microsoft Entra ID Identity Protection through premium licenses Temporary Credentials IAM roles provide temporary credentials Microsoft Entra Id PIM for temporary privileges through premium licenses Cross-Service Permissions IAM policies across services Unified role model across services via Azure RBAC Data protection Understanding the differences in data protection between AWS and Azure is crucial for you as an Independent Software Vendor (ISV) navigating the migration process. Recognizing these distinctions will help you make informed decisions and ensure a smoother transition. AWS: AWS offers key management through KMS, data classification with Macie, and monitoring with CloudTrail. Key features include S3 Object Locking and robust encryption for data both at rest and in transit. Azure: Azure uses Key Vault for key management, Purview for data classification, and provides Blob Storage versioning and immutability. It also offers built-in data retention, comprehensive auditing features, and advanced security via Microsoft Sentinel. Feature AWS Data Protection Azure Data Protection Data Encryption at Rest Encryption by Default on S3, EBS, RDS, etc. Encryption option of other services Encryption by Default on Blob Storage, Azure SQL DB, Azure Managed Disks, etc. Encryption options for other services Data Encryption in Transit SSL/TLS Encryption SSL/TLS Encryption Key Management AWS KMS (encryption key management), CloudHSM: hardware based key management) Azure Key Vault (encryption key management), Dedicated HSM (hardware based key management) Bring Your Own Key (BYOK) Supported Supported BYOK Key Rotation Automatic Automatic Data Classification Amazon Macie Azure Purview Data Masking RDS Column-Level Encryption Azure SQL Database and Azure Synapse Analytics offer Dynamic Data Masking Backup and Recovery AWS backup Azure backup Data Retention Policies AWS Data Lifecycle Manager Azure Blob Storage Lifecycle Management Compliance and Certifications Various Standards Various Standards Data Loss Prevention S3 Versioning Blob Storage Data Integrity and Authenticity S3 Object Locking to enforce WORM protection for data immutability Immutable Blob Storage features WORM Network Data Protection VPC with encryption, security groups, and network ACLs to protect data in transit. AWS Shield and WAF provide additional network-level security VNet with encryption, network security groups (NSG), and private endpoints to secure data in transit. DDoS Protection and WAF for network security End-to-End Encryption KMS or CloudHSM Azure Key Vault, TLS Data Deletion and Wiping S3 Lifecycle Policies Blob Storage Secure Deletion policies File-Level Encryption EFS Encryption including file-level encryption using KMS Azure Files Encryption using Azure Key Vault Data Access Auditing CloudTrail, CloudWatch Azure Monitor, Security Center, Microsoft Sentinel for advanced threat detection and alerting Threat detection and monitoring Both AWS and Azure offer robust tools for threat detection and monitoring, but Azure provides a more integrated approach, especially in hybrid and multi-cloud environments. Azure's services, such as Azure Security Center and Microsoft Sentinel, work seamlessly with third-party solutions like Palo Alto Networks, CrowdStrike, and McAfee, offering centralized management and easier threat detection. AWS: AWS provides Amazon GuardDuty for threat detection and AWS Security Hub for centralized security monitoring. Additionally, CloudTrail logs API activity, and AWS Config monitors resource configurations. Azure: Azure offers Azure Security Center for threat management and Microsoft Sentinel for SIEM and incident response. Microsoft Defender for Cloud protects various workloads across hybrid and multi-cloud environments. Feature AWS Azure Core Threat Detection GuardDuty Security Center Real-Time Monitoring Amazon CloudWatch Azure Monitor Anomaly Detection GuardDuty Security Center & Microsoft Sentinel Advanced Threat Analytics GuardDuty Microsoft Sentinel Threat Intelligence GuardDuty Microsoft Sentinel Malware Detection AWS Maice Microsoft Defender for Cloud Log Management Amazon CloudWatch Logs, AWS CloudTrail Azure Monitor, Azure Log Analytics Incident Response Centralized Security Hub Security Center & Microsoft Sentinel integrated management Compliance Monitoring AWS Config Security Center Vulnerability Scanning AWS Inspector Microsoft Defender for Cloud for Servers Network Threat Detection VPC Flow Logs & AWS Network Firewall Azure Network Watcher & Azure Firewall DDoS Protection AWS Shield Azure DDoS Protection Behavioral Analytics GuardDuty Microsoft Sentinel Cloud & Hybrid Environment Support GuardDuty, AWS Security Hub & CloudWatch Azure Security Center & Microsoft Sentinel Automation & Orchestration AWS Security Hub & Lambda Microsoft Sentinel & Azure Logic Apps External Threat Intelligence Integration GuardDuty Microsoft Sentinel Integrated Endpoint Protection AWS Endpoint Protection (via Amazon Macie, AWS Security Hub, and other services) Microsoft Defender for Cloud for Endpoint (integrated with Microsoft Sentinel) Compliance and certifications Both AWS and Azure are highly compliant with international standards, offering a range of certifications to meet industry-specific requirements. However, they differ in their approach to compliance management. Azure integrates compliance into the platform via tools like Azure Policy, Microsoft Defender for Cloud and Compliance Manager, enabling continuous management and policy enforcement. Azure’s focus on hybrid and multi-cloud environments makes it a strong choice for complex compliance needs. AWS: AWS offers a broad range of global compliance certifications, including ISO 27001, SOC 1/2/3, PCI-DSS, HIPAA, GDPR, and FedRAMP. Compliance is primarily managed via AWS Artifact, offering access to reports and documentation, with an emphasis on self-service tools for compliance across industries. Azure: Azure supports a variety of compliance certifications, including ISO 27001, SOC 1/2/3, PCI-DSS, HIPAA, GDPR, and FedRAMP, and places greater emphasis on proactive compliance management. It integrates compliance into the platform via tools like Azure Policy and Compliance Manager. These tools help you manage compliance and enforce policies. Azure’s focus on hybrid and multi-cloud environments, as well as industry-specific certifications, makes it a compelling choice for organizations with complex compliance needs. Network security Network security is crucial in any cloud environment, and both AWS and Azure provide tools to protect applications and data. While both offer strong security solutions, they differ in how they approach network security and integration. By understanding these differences, you can leverage Azure and its built-in services to build a robust and secure network. AWS: AWS focuses on network isolation and scalable connectivity through VPC (Virtual Private Cloud), allowing you to create isolated virtual networks in the AWS cloud. This gives you complete control over IP address ranges, subnets, and routing, allowing for granular control. AWS provides AWS Shield for DDoS protection, AWS WAF (Web Application Firewall) to protect web applications, and AWS Transit Gateway to facilitate secure connectivity across VPCs and on-premises environments. While these tools offer extensive customization, they require a higher level of setup and integration to ensure robust security across complex environments. Azure: Azure's approach to network security is centered around the Azure Virtual Network (VNet), which serves a similar purpose to Amazon VPC by allowing you to create isolated network environments in the Azure cloud. Azure simplifies network management by providing built-in features for connectivity, including VNet Peering for secure connections between VNets, as well as integration with Azure ExpressRoute for private connections to on-premises infrastructure. Azure also offers Azure DDoS Protection for safeguarding applications from large-scale attacks, Azure Firewall for filtering traffic, and Azure Network Security Groups (NSGs), which provide detailed control over inbound and outbound traffic to resources within a VNet. The integration of these security tools with other Azure management services makes it easier for you to manage and enforce security policies in hybrid cloud and multi-cloud environments. Aspect AWS Azure Virtual Network Setup Amazon VPC for isolated networks with subnets, route tables, and private/public IPs Azure VNet with similar capabilities for isolated networks with segmented subnets and route tables Firewall Services AWS Network Firewall and AWS WAF for web app security Azure Firewall and Azure WAF for web app protection Private Connectivity AWS Direct Connect Azure ExpressRoute Intrusion Detection AWS GuardDuty for threat detection and monitoring Azure Security Center with integrated threat protection and Microsoft Defender for Cloud VPN Support AWS VPN for secure site-to-site IPsec connections Azure VPN Gateway for secure IPsec/IKE site-to-site connections Network Segmentation AWS Security Groups at Instance level. NACLs at subnet level. Azure NSGs for instance traffic filtering and Application Security Groups for segmentation DDoS Protection AWS Shield with Standard and Advanced DDoS protection Azure DDoS Protection with Standard and Basic plans Load Balancing AWS ELB for application and network load balancing Azure Load Balancer and Application Gateway for layer 7 load balancing and WAF Traffic Inspection AWS Traffic Mirroring Azure Network Watcher Private Link AWS PrivateLink Azure Private Link Bastion Hosts AWS EC2 Instance Connect for secure SSH/RDP without public IPs, AWS Systems Manager Session Manager for remote instance connection Azure Bastion for secure RDP/SSH to Azure VMs without public exposure RDP/SSH Access AWS Systems Manager Session Manager for secure, auditable EC2 instance access with no bastion host Azure Bastion for secure, managed RDP/SSH VM access without open ports Key Resources: Publishing to commercial marketplace documentation Pricing Calculator | Microsoft Azure Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV Success Maximize your momentum with step-by-step guidance to publish and grow your app with App Advisor Accelerate your development with cloud ready deployable code through the ISV quick-start development toolkitMigrating your AWS offer to Microsoft Marketplace - Identity and Access Management (IAM)
As a software development company, expanding your marketplace presence beyond AWS Marketplace to include Microsoft Marketplace can open new doors to grow your customer base. Azure’s broad ecosystem and diverse user base offer a dynamic platform to enhance your application’s reach and potential. This post is part of a series on replicating apps from AWS to Azure. View all posts in this series. Expand your reach and accelerate growth by bringing your AWS-based app to Azure and selling through Microsoft Marketplace. This guide will break down key IAM differences between AWS and Microsoft Entra ID, helping you replicate your app’s identity management quickly and securely. Future posts will dive deeper into specific IAM configurations and best practices. You can also join ISV Success to get access to over $126K USD in cloud credits, AI services, developer tools, and 1:1 technical consults to help you replicate your app and publish to Marketplace. To ensure a smooth app replication, start by understanding the key differences between AWS IAM and Microsoft Entra ID. A clear grasp of these distinctions will help you transition identity management effectively while optimizing security and performance on Azure. This guide will highlight these differences, map comparable services, and provide actionable steps for a seamless IAM replication. This article addresses Identity and Access Management (IAM) and select Identity Services: Amazon Cognito vs. Microsoft Entra ID. Identity and Access management (IAM) Identity and Access Management (IAM) is essential for securing and managing who can access resources, under what conditions, and with what specific permissions. AWS and Azure both offer robust IAM solutions to manage identities, roles, and policies, but they differ significantly in architecture, integration capabilities, and ease of use, particularly for software companies building SaaS solutions migrating from AWS to Azure. Users, Groups, and Roles AWS IAM creates users within an AWS account, grouping them into IAM User Groups, while Azure IAM manages users as directory objects in Microsoft Entra ID, assigning permissions via Azure RBAC. Both support MFA and identity federation through SAML, Azure enforcing Conditional Access based on location, device state, and user risk. AWS IAM grants permissions using JSON-based policies, allowing roles to be assumed by users, AWS services, or external identities without permanent credentials. Azure IAM assigns permissions via RBAC to users, groups, and service principals, offering predefined and customizable roles. Azure supports federated identity for hybrid environments, while Azure integrates with on-premises Microsoft Entra ID. Permissions and Policies AWS IAM employs JSON-based policies for granular permissions across AWS services. Policies can be identity-based, directly attached to users or roles, or resource-based, applied directly to resources such as S3 buckets or DynamoDB tables. AWS supports temporary credentials via roles, which can be assumed by users, AWS services, or external federated identities. Azure RBAC leverages predefined roles (e.g., Global Administrator, Contributor, Reader) or custom roles, offering clear hierarchical permissions management across resource, resource group, subscription, or management group levels. AWS also allows conditional permissions through advanced policy conditions (e.g., IP address, MFA status, tags). Azure IAM employs Conditional Access Policies, adjusting access based on location, device state, and user risk. AWS IAM grants access only when explicitly allowed, whereas Azure IAM evaluates role assignments and conditions before permitting actions. For multi-account and cross-tenant access, AWS IAM enables secure cross-account roles, while Azure IAM supports External Identities for inter-tenant collaboration. AWS IAM delegates administrative rights using roles and policies, whereas Azure IAM assigns administrative roles within organizations for delegated management. AWS IAM enables controlled, temporary access to S3 objects using pre-signed URLs, which grant time-limited access to specific resources without modifying IAM policies. These URLs are often used for secure file sharing and API integrations. In Azure, a similar concept exists with Shared Access Signatures (SAS) Keys, which provide scoped and time-limited access to Azure Storage resources like Blob Storage, Table Storage, and Queues. Unlike pre-signed URLs, SAS keys allow granular control over permissions, such as read, write, delete, or list operations, making them more flexible for temporary access Integration with External Identities Both platforms provide Single Sign-On (SSO). AWS IAM uses AWS SSO. Microsoft Entra ID also supports SSO with SAML, OAuth, and OIDC. For federated identities, AWS IAM allows external users to assume roles, while Microsoft Entra ID assigns roles based on its access model. Hybrid environments are supported through on-premises directory integration. AWS IAM connects to Active Directory via AWS Directory Service, while Microsoft Entra ID integrates with on-prem AD using Microsoft Entra ID Connect, enabling hybrid identity management and SSO for cloud and on-prem resources. Both support automated user provisioning: AWS IAM utilizes AWS SSO and federation services, while Microsoft Entra ID supports SCIM 2.0 for third-party applications and syncs on-prem AD via Entra ID Connect. AWS IAM enables ECS, EKS, and Lambda workloads to pull container images from Amazon Elastic Container Registry (ECR) using IAM roles. These roles grant temporary permissions to fetch container images without requiring long-term credentials. In Azure, Azure Container Registry (ACR) authentication is managed through Service Principals and Managed Identities. Instead of IAM roles, Azure applications authenticate using Entra ID, allowing containers to securely pull images from ACR without embedding credentials. Access Control Models AWS IAM uses a policy-based access model, where permissions are defined in JSON policies attached to users, groups, or roles. In contrast, Azure separate's identity management via Microsoft Entra ID from access management via Azure RBAC, which assigns roles to users, groups, service principals, or managed identities to control access to Azure resources. Both provide fine-grained access control. AWS IAM sets permissions at the resource level (e.g., EC2, S3), while Azure uses Azure RBAC to assign Microsoft Entra ID identities roles that apply hierarchically at the resource, subscription, or management group levels. Both follow a default "deny" model, granting access only when explicitly allowed. For multi-account and multi-tenant support, AWS IAM enables cross-account roles. Microsoft Entra organizations can use External ID cross-tenant access settings to manage collaboration with other Microsoft Entra organizations and Microsoft Azure clouds through B2B collaboration and B2B direct connect. Delegation is managed through IAM roles in AWS and RBAC role assignments in Azure. Conditional access is supported—AWS uses policy-based conditions (e.g., time-based, IP restrictions), while Microsoft Entra ID relies on Conditional Access Policies (e.g., location, device health, risk level). AWS allows cross-account policy sharing, while Microsoft Entra ID enables role-based delegation at different organizational levels. Both support cross-service permissions, AWS IAM policies can define access across multiple AWS services, while Azure uses Azure RBAC to assign Microsoft Entra ID identities permissions across Azure services such as Blob Storage, SQL Database, and Key Vault. For workload authentication, AWS IAM roles provide temporary credentials for EC2, Lambda, and ECS, eliminating hardcoded secrets. In Azure, Microsoft Entra ID enables Managed Identities, allowing applications running on Azure services to authenticate securely to other Azure resources without managing credentials. Additionally, Microsoft Entra Workload Identities allow Kubernetes workloads—especially on AKS—to authenticate using Entra ID via OpenID Connect (OIDC), streamlining access to Azure services in containerized and multi-tenant environments. In AWS, containerized workloads such as ECS, EKS, and Lambda use IAM roles to securely authenticate and pull images from Amazon ECR, avoiding hardcoded credentials. In Azure, containerized applications authenticate to Azure Container Registry (ACR) using Microsoft Entra ID identities—either Managed Identities or Service Principals. Permissions such as AcrPull are granted via Azure RBAC, enabling secure image access. Azure’s model supports cross-tenant authentication, making it particularly useful for ISVs with multi-tenant containerized SaaS deployments. Cross-account storage access in AWS uses IAM roles and bucket policies for Amazon S3, allowing external AWS accounts to securely share data. In Azure, Microsoft Entra ID B2B and RBAC assignments. This model avoids the need to share credentials or manage access via SAS tokens, streamlining collaborations in multi-tenant environments. Audit and Monitoring AWS IAM and Microsoft Entra ID both provide robust audit logging and monitoring. AWS CloudTrail logs IAM and AWS API calls for 90 days by default, with extended retention via CloudTrail Lake or Amazon S3. Microsoft Entra ID logs sign-ins, including failed attempts, retaining data for 7 days in the free tier and up to 30 to 90 days in Premium tiers. For longer retention, Log Analytics or Sentinel should be used. For real-time monitoring, AWS CloudWatch tracks IAM activities like logins and policy changes, while Microsoft Entra ID Premium does so via Azure AD Identity Protection. AWS uses CloudWatch Alarms for alerts on permission changes, whereas Microsoft Entra ID alerts on suspicious sign-ins and risky users. AWS GuardDuty detects IAM threats like unusual API calls or credential misuse, while Microsoft Entra ID’s Identity Protection identifies risky sign-ins (Premium P2 required). AWS Security Hub aggregates findings from CloudTrail and GuardDuty, while Microsoft Entra ID integrates with Azure Sentinel for advanced security analytics. For IAM configuration tracking, AWS Config monitors policies and permissions, while Microsoft Entra ID’s Audit Log track's role, group, and user changes. AWS Artifact provides downloadable compliance reports. Microsoft Purview Compliance Manager enables customers to assess and manage their compliance across services like Entra ID and Azure using built-in control assessments. AWS CloudTrail logs IAM activity across AWS Organizations, and Microsoft Entra ID Premium supports cross-tenant access monitoring. Azure Lighthouse enables cross-tenant management for service providers, integrating with Microsoft Entra ID for delegated access without guest accounts. It applies RBAC across tenants and manages shared resources like Azure Blob Storage and virtual machines, streamlining ISV operations in marketplace scenarios. Pricing AWS IAM and Microsoft Entra ID provide core IAM services for free, with advanced features available in paid tiers. Both platforms support unlimited users for basic IAM functions, with AWS offering free user, role, and policy creation, while Microsoft Entra ID allows up to 500,000 objects (users/groups) at no cost. Additional users can be added for free, though advanced features require a paid plan. MFA is free on both platforms, but Microsoft Entra ID includes advanced MFA options in Premium tiers. AWS does not have risk based Conditional Access for free. Microsoft Entra ID includes it in Premium P1/P2 tiers (starting at $6 per user/month) Custom policies for fine-grained access control are free in AWS and Azure. Identity federation is free in AWS IAM, while Microsoft Entra ID requires a Premium P1/P2 plan. Microsoft Entra ID includes Self-Service Password Reset (SSPR) in Premium P1/P2, whereas AWS IAM does not offer it for free. Both platforms support RBAC at no extra cost. Directory synchronization is available via Microsoft Entra ID Premium P1/P2. AWS Directory Service is a paid managed AD service, not part of IAM. AWS IAM doesn’t have a direct “guest user” concept; instead, you configure federated access or cross-account roles, but Microsoft Entra ID requires a Premium tier for Azure AD External Identities. Full API and CLI access for user, policy, and role management is free on both platforms. Advanced security monitoring is available through AWS GuardDuty and Security Hub at an extra cost. Microsoft Entra ID provides advanced security monitoring, such as risk-based conditional access, within Premium P1/P2 tiers. Both platforms offer free support for service principals, enabling secure application access and role assignments. Amazon Cognito vs. Microsoft Entra ID Amazon Cognito provides identity and access management for applications in AWS, while Azure offers this through Microsoft Entra ID, centralizing IAM tools for ISVs. Both differ in authentication, integration, and target audiences. User management Amazon Cognito uses User Pools for authentication and Identity Pools for federated identities. Microsoft Entra ID serves as a central identity directory for Azure, Microsoft 365, and third-party apps, integrating with on-prem AD. Authentication methods Both support password-based login, MFA, passwordless authentication, and social sign-in. Amazon Cognito can be extended to support passwordless authentication with magic links, OTPs, and FIDO2 using AWS Lambda. Microsoft Entra ID supports native passwordless options like FIDO2, Windows Hello, and OTPs, plus risk-based conditional authentication. Identity Federation & SSO Amazon Cognito supports SAML, OAuth 2.0, and OIDC. Microsoft Entra ID offers enterprise SSO with SAML, OAuth, and WS-Federation, plus cross-tenant federation via Entra ID B2B. Access Control & Security Policies AWS relies on AWS IAM and custom logic for built-in RBAC or Attribute Based Access Control (ABAC). Microsoft Entra ID includes RBAC, ABAC, and Conditional Access Policies for granular security control. Self-Service & User Management Amazon Cognito allows self-registration and password resets, with workflow customization via AWS Lambda. Microsoft Entra ID offers SSPR, access reviews, and an enterprise portal for account management. Security & Compliance Amazon Cognito provides monitoring via AWS CloudTrail and GuardDuty, compliant with HIPAA, GDPR, and ISO 27001. Microsoft Entra ID integrates with Microsoft Defender for Identity for threat detection, with compliance for HIPAA, GDPR, ISO 27001, and FedRAMP, plus risk-based authentication in premium tiers. Migration best practices tips When migrating IAM from AWS to Azure, organizations should: Assess existing AWS IAM policies and roles, mapping them carefully to Azure RBAC roles. Leverage Microsoft Entra Connect for seamless integration with existing on-premises Active Directory environments. Use Azure's Managed Identities and SAS tokens strategically to minimize credential management complexity. Implement Conditional Access Policies in Azure to dynamically secure and simplify access management. Key Resources: Microsoft Azure Migration Hub | Microsoft Learn Publishing to commercial marketplace documentation Pricing Calculator | Microsoft Azure Azure IAM best practices Configure SAML/WS-Fed identity provider - Microsoft Entra External ID Maximize your momentum with step-by-step guidance to publish and grow your app with App Advisor Accelerate your development with cloud ready deployable code through the Quick-start Development Toolkit
