How do AKS and AKS on Azure Stack HCI compare?
This blog is an update to the original blog published comparing AKS in Azure and on Azure Stack HCI, a year ago. Since then, we’ve released multiple features and fixes aimed at improving AKS consistency between Azure and on-premises that warranted a fresh blog 😊 Features in preview are marked by (*) Feature Set AKS on Azure Stack HCI & AKS on Windows Server AKS Kubernetes Management Cluster/AKS host AKS on Azure Stack HCI and Windows Server is a Cluster API based hosted Kubernetes offering. A management Kubernetes cluster is used to manage Kubernetes workload clusters. The management Kubernetes cluster runs in customer datacenters and is managed by the infrastructure administrator. AKS is a managed Kubernetes offering. AKS control plane is hosted and managed by Microsoft. AKS worker nodes are created in customer subscriptions. Kubernetes Target Cluster (lifecycle operations) Cloud Native Computing Foundation (CNCF) certification Yes Yes Who manages the cluster? Managed by you Managed by you Where is the cluster located? In your datacenter alongside your AKS hybrid management cluster. Azure Stack HCI 21H2 Windows Server 2019 Datacenter Windows Server 2022 Datacenter Windows 10/11 IoT Enterprise* Windows 10/11 Enterprise* Windows 10/11 Pro* Azure cloud K8s cluster lifecycle management tools (create, scale, update and delete clusters) PowerShell (PS) Windows Admin Center (WAC) Az CLI* Azure Portal* ARM templates* Az CLI Az PowerShell Azure Portal Bicep ARM templates Can you use kubectl and other open-source Kubernetes tools? Yes Yes Workload cluster updates K8s version upgrade through PowerShell or WAC. Initiated by you. Node OS image update initiated by you; Updates in a target cluster happen at the cluster level – control plane nodes + node pools updated. Azure CLI, Azure PS, Portal, ARM templates, GitHub Actions; OS image patch upgrade; Automatic upgrades; Planned maintenance windows; Kubernetes versions Continuous updates to supported Kubernetes versions. For latest version support, visit AKS hybrid releases on GitHub. Continuous updates to supported Kubernetes versions. For latest version support, run az aks get-versions. Can you start/stop K8s clusters to save costs? Yes, by stopping the underlying failover cluster Yes Azure Fleet Manager integration Not yet. Yes* Terraform support Not yet. Yes Node Pools Do you support running Linux and Windows node pools in the same cluster? Yes! Linux nodes: CBL-Mariner Windows nodes: Windows Server 2019 Datacenter, Windows Server 2022 Datacenter Yes. Linux nodes: Ubuntu 18.04, CBL-Mariner Windows nodes: Windows Server 2019 Datacenter Windows Server 2022 Datacenter What’s your container runtime? Linux nodes: containerd Windows nodes: containerd Linux nodes: containerd Windows nodes: containerd Can you scale node pools? Manually Cluster autoscaler Vertical pod autoscalar Manually Cluster autoscaler Vertical pod autoscalar Horizontal pod autoscalar Yes Yes What about virtual nodes? Azure container instance No Yes Can you upgrade a node pool? We do not support upgrading individual node pools. All upgrades happen at the K8s cluster level. You can perform node pool specific upgrades in an AKS cluster. GPU enabled node pools Yes* Yes Azure Container Registry Yes Yes KEDA support Not yet Yes* Networking Who creates and manages the networks? All networks (for both the management cluster and target K8s clusters) are created and managed by you By default, Azure creates the virtual network and subnet for you. You can also choose an existing virtual network to create your AKS clusters What type of network options are supported? DHCP networks with/without VLAN ID Static IP networks with/without VLAN ID SDN support for AKS on Azure Stack HCI Bring your own Azure virtual network for AKS clusters. Load balancers HAProxy (default) runs in a separate VM in the target K8s cluster kubeVIP – runs as a K8s service in the control plane K8s node Bring your own load balancer Load balancers are always given sIP addresses from a customer vip pool to ensure application and K8s cluster availability. You can create multiple instances of a LB (active-passive) for high availability Azure load balancer – Basic SKU or Standard SKU Can also use internal load balancer By default, load balancer IP address is tied to load balancer ARM resource. You can also assign a static public IP address directly to your Kubernetes service CNI/Network plugin Calico (default) Note: Network policies are covered in the Security and Authentication section. Azure CNI Calico Azure CNI Overlay Bring your own CNI Note: Network policies are covered in the Security and Authentication section. Ingress controllers No but you can use 3 rd party addons – Nginx. 3 rd party addons are not supported by Microsoft’s support policy. Support for Nginx with web app routing addon. Egress controls Egress is controlled by Network policies, by default all outbound traffic from pods is blocked. You can deploy additional egress controls and policies. You can use Azure Policy and NSGs to control network flow or use Calico policies. You can also use Azure FW and Azure Security Groups. Egress types Egress types and options depend on your network architecture. Azure load balancer, managed NAT gateway and user defined routes are the supported egress types. Customize CoreDNS Allowed Allowed Service Mesh Yes, Open Service Mesh (OSM) through Azure Arc enabled Kubernetes. 3 rd party addons – Istio, etc. 3 rd party addons are not supported by Microsoft’s support policy. Open Service Mesh Marketplace offering available for Istio Storage Where is the storage provisioned? On-premises Azure Storage. Azure Files and Azure Disk premium CSI drivers deployed by default. You can also deploy any custom storage class. What types of persistent volumes are supported? Read Write Once Read Write Many Read Write Once Read Write Many Do the storage drivers support Container Storage Interface (CSI)? Yes Yes Is dynamic provisioning supported? Yes Yes Is volume resizing supported? Yes Yes Are volume snapshots supported? No Yes Security and Authentication How do you access your Kubernetes cluster? Certificate based kubeconfig (default) AD based kubeconfig Azure AD and Kubernetes RBAC Azure AD and Azure RBAC* Certificate based kubeconfig (default) Azure AD and Kubernetes RBAC Azure AD and Azure RBAC Network Policies Yes, we support Calico network policies Yes, we support Calico and Azure CNI network policies Limit source networks that can access API server Yes, by using VIP pools. Yes, by using the “-api-server-authorized-ip-ranges” parameter and private clusters. Certificate rotation and secrets encryption Yes Yes Support for private cluster Not supported yet Yes! You can create private AKS clusters Secrets store CSI driver Yes Yes Support for disk encryption Yes, via bitlocker Disks are encrypted on the storage side with platform managed keys and with support for customer provided keys. Hosts and locally attached disks can also be encrypted with encryption at host. gMSA v2 support for Windows containers Yes Yes Azure Policy Yes, through Azure Arc enabled K8s Yes Azure Defender Yes, through Azure Arc enabled K8s* Yes Monitoring and Logging Collect logs Yes, through PS and WAC. All logs – management cluster, control plane nodes, target K8s clusters are collected. Yes, through Azure Portal, Az CLI, etc Support for Azure Monitor Yes, through Azure Arc enabled K8s. Yes 3 rd party addons for monitoring and logging AKS works with Azure managed Prometheus* and Azure managed Grafana* Subscribe to Azure Event Grid Events Yes, via Azure Arc enabled Kubernetes* Yes Develop and run applications Azure App service Yes, through Azure Arc enabled K8s* Yes Azure Functions Yes, through Azure Arc enabled K8s* Yes Azure Logic Apps Yes, through Azure Arc enabled K8s* You can directly create App Service, Functions, Logic Apps on Azure instead of creating on AKS Develop applications using Helm Yes Yes Develop applications using Dapr Yes, through Azure Arc enabled K8s* Yes DevOps Azure DevOps via Azure Arc enabled K8s. GitHub Actions via Azure Arc enabled K8s. GitOps Flux v2 via Azure Arc enabled K8s. 3 rd party addon: ArgoCD. 3 rd party addons are not supported by Microsoft’s support policy. GitOps Flux v2 through Azure Arc enabled Kubernetes is free for AKS-HCI customers. Azure DevOps GitHub Actions GitOps Flux v2 Product Pricing Product pricing If you have Azure Hybrid Benefit, you can use AKS-HCI at no additional cost. If you do not have Azure Hybrid Benefit pricing based on number of workload cluster vCPUs. Management cluster, control plane nodes, load balancers are free. Unlimited free clusters, pay for on-demand compute of the worker nodes. Paid tier available with uptime SLA, support for 5k nodes. Azure Support AKS-HCI is supported out of the Windows Server support organization aligned with Arc for Kubernetes and Azure Stack HCI. You can open support requests through the Azure portal and other support channels like Premier Support. AKS in Azure is supported through enterprise class support in the Azure team. You can open support requests in the Azure portal. SLA We do not offer SLAs since AKS-HCI runs in your environment. Paid uptime SLA clusters for production with fixed cost on the API + worker node compute, storage and networking costs.Modern Azure Resilience with Mark Russinovich
Resiliency in the cloud reflects different priorities from consistent performance, to withstanding failures, to predictable recovery. These map to reliability, resiliency, and recoverability, which together guide how workloads should be designed on Azure. This post extends foundational guidance with practical multi‑region design decisions, including when to use availability zones, paired regions, and non‑paired regions to meet business continuity goals. Reliability in Azure isn’t defined by a single recommendation, but by a set of architectural patterns designed to balance cost, complexity, recovery speed, and operational effort—because no single approach fits every workload. While disaster recovery is a common driver for multi‑region designs, long‑term scale planning also matters. Azure regions operate within defined physical and latency boundaries, and large-scale workloads may eventually approach the practical capacity limits of a single region. This post introduces four resilience patterns, outlining when and why to use each so you can assess options based on your non‑functional requirements. It also explains how availability zone–based designs can often provide an alternative to paired regions as a default choice. Here are a few common reliability and availability architecture patterns: In-region High Availability (HA) with Availability Zones (AZ): Maximize availability within a single Azure region by deploying across multiple availability zones. Regional Business Continuity and Disaster Recovery (BCDR): A primary/secondary region strategy implemented across separate Azure regions, selected based on geographic risk boundaries, regulatory requirements, and service availability. Recovery sequencing and failover behaviors are defined by workload dependencies and organizational requirements. Non-paired region BCDR: A primary/secondary region strategy where the secondary region is chosen based on requirements such as capacity, service availability, data residency, and network latency. This approach also supports long‑term scale planning, since Azure regions operate within physical datacenter footprints and latency boundaries and can reach practical capacity limits as workloads grow. See multi‑region solutions in non‑paired regions. Multi-region active/active: Deploy workloads across multiple regions simultaneously so that each region can serve production traffic. This approach can provide both high availability and disaster resilience while improving global performance, but it introduces additional architectural complexity and operational overhead. The rest of this post helps you understand the tradeoffs across these patterns, enabling you to select the right approach per workload while avoiding unnecessary cost and operational complexity. First post in this series: Achieve agility and scale in a dynamic cloud world Why did Azure launch with paired regions? Launched in 2010, but rebranded to Microsoft Azure in 2014, the regions were introduced in pairs (West US & East US, West Europe & North Europe, Southeast Asia & East Asia) to align with common enterprise business continuity practices at the time. Many organizations operated multiple datacenters within the same geographic boundary, separated by sufficient distance to reduce shared risk while maintaining regulatory and operational alignment. This design mirrored familiar enterprise BCDR practices at the time and offered: A familiar primary/secondary failover pattern consistent with enterprise BCDR strategies Support for regulatory or data residency requirements that required disaster recovery within a defined geographic boundary Turnkey replication capabilities for services such as Geo-Redundant Storage (GRS) Platform-level sequencing of updates to reduce the likelihood of simultaneous regional impact A defined regional recovery prioritization model for rare geography-wide incidents This model provided assurance that Azure could meet or exceed the resilience of legacy enterprise environments while simplifying early cloud adoption through predefined recovery patterns. However, Azure’s engineering strategy has evolved. Many services now support replication to a region of choice rather than being limited to predefined pairs. This provides architects with greater flexibility to select regions based on workload requirements, risk boundaries, compliance constraints, capacity considerations, and cost models. It’s important to recognize that regional parity is never guaranteed even between paired regions. Differences in service availability, supported SKUs, scale limits, capacity, cost and operational maturity must be explicitly accounted for in the workload design. How has cloud resilience evolved since launch? The introduction of Availability Zones in 2018 provides a significant advancement in Azure resilience. Availability Zones are physically isolated groups of data centers within a region; each zone has independent power, cooling and networking. Many Azure services (App Service, Storage, Azure SQL etc.) use zones to provide platform-managed resilience. In addition, customers can deploy zonal resources, such as virtual machines, into specific zones or distribute them across zones to design for higher availability. Where previously Azure regions were launched in pairs, since 2020, regions have been typically designed with multiple availability zones, without a paired region. This design enables: High availability within a single region Platform-managed resilience for most failure scenarios Reduced need for multi-region deployments for standard high-availability requirements How should customers design for resilience when using both paired and non-paired regions? To decide which resiliency model makes sense, customers should start by defining clear expectations including uptime targets, recovery time objectives (RTO), recovery point objectives (RPO), latency tolerance, and data residency. These non-functional requirements should directly influence architectural decisions. In practice, High Availability (HA) and Disaster Recovery (DR) are differentiated by recovery objectives rather than geography. HA architectures target near-zero downtime and minimal data loss, while DR solutions allow for defined recovery time and acceptable data loss. While HA is commonly established within a region using availability zones, it can also be achieved across regions through active-active designs. Similarly, DR is typically implemented across regions using replication and failover strategies. HA: Availability Zones When designing high availability within a region, Azure builds on AZs with 2 models: Zone-redundant resources are replicated across multiple availability zones to ensure data remains accessible even if one zone fails. Some services provide built-in zone redundancy, while others require manual configuration. Typically, Microsoft chooses the zones used for your resources, though some services allow you to select them. Zonal resources are deployed in a single availability zone and do not provide automatic resiliency against zone outages. While faults in other zones do not affect them, ensuring resiliency requires deploying separate resources across multiple zones. Microsoft does not handle this process; you are responsible for managing failover if an outage occurs. The decision to design a zone-resilient architecture is critical for balancing availability requirements with cost and regional capacity constraints. Designing workloads to be resilient across availability zones is generally the preferred approach for improving availability and protecting against zone-level failures. Deploying workloads across availability zones can enhance fault tolerance and reduce downtime when supported by the Azure service being used. However, architects should still consider workload characteristics, cost implications, and potential latency impacts, which may vary depending on the services and architecture patterns involved. Ultimately, zone resiliency is an architectural decision that should be strategically aligned with business priorities and risk tolerance, not simply treated as a checkbox to be ticked during deployment. DR: Paired and Non-Paired Regions Region pairs should be viewed as an architectural choice rather than a rule. Historically, paired regions played a key role in minimizing correlated failures and streamlining platform updates and recovery processes. However, as the Azure Safe Deployment Practices (SDP) have matured, the advantages of region pairs have become more nuanced. Over time, SDP has evolved to support safer and more flexible change management through longer and more adaptable bake times, richer operational signal integration, and an expanded understanding of regional deployment boundaries. These improvements enable Azure to release changes more safely across a growing and increasingly diverse regional footprint, while still balancing reliability with time‑to‑market. As a result, regional pairs are no longer the sole mechanism for managing correlated change risk, but one of several architectural tools customers can apply based on their resiliency and compliance needs. Using non-paired regions or a mix of paired and non-paired regions allows customers to design high availability and disaster recovery architectures that are driven by business, compliance, and application requirements rather than fixed regional relationships. This enables customers to optimize data residency, regulatory boundaries, latency to specific user populations, and provide differentiated recovery objectives across their workloads. This approach can also reduce exposure to rare but high-impact platform-level events by avoiding tightly coupled regional behaviors. While some Azure services natively simplify replication and recovery within paired regions, and others support replication across arbitrary regions (such as Azure SQL, Cosmos DB, and Azure Blob Storage with object replication), non-paired designs encourage explicit, workload-aware resiliency strategies such as application-level replication, asynchronous data sync, and failover orchestration. Although this introduces more architectural responsibility and may require compensating for paired region features, it delivers greater transparency, predictable recovery behavior, and alignment with business-driven RTO/RPO requirements rather than platform defaults. Regional failover is a customer‑orchestrated decision; customers should design, test, and operate their own failover and failback processes rather than assuming platform‑initiated regional failover. Designing for regional resilience requires distinguishing between workload mobility and data protection. Azure provides two complementary capabilities that address these needs differently: Azure Site Recovery (ASR) and Azure Backup. Azure Site Recovery (ASR) enables near‑continuous replication and orchestrated failover of virtual machine–based workloads to a region of choice, not limited to paired regions. ASR is the primary mechanism for customers who need low RPO, controlled failover, and workload restart in a secondary region. This is especially relevant for regions without a paired region or where the paired region does not meet capacity, service availability, or compliance needs. Azure Backup provides durable, policy‑based data protection, independent of compute availability. While Azure Backup is not a high‑availability or infrastructure failover solution, it plays a critical role when services do not support region‑of‑choice replication natively. In these scenarios, backup and restore become the recovery mechanism. These two services are often used together: ASR for VM‑level workload continuity, and Azure Backup for protecting and restoring data across regions, including to non‑paired regions. I am using paired regions today – does this mean I need to change my architecture? If your current architecture is built around paired regions for compliance, data residency, or strict disaster recovery objectives, that model stays valid and supported. Azure continues to support paired regions providing prioritized recovery sequencing, staggered platform updates, and geo-aligned data residency, all backed by Microsoft’s global infrastructure strategy. What has changed is that paired regions are no longer the only way to achieve enterprise-grade resilience. For many workloads that adopted a paired region (1+1) model primarily to protect against local datacenter failure, Availability Zones combined with geo-redundant services now provide equivalent or better protection with far less architectural complexity and cost. The shift to nonpaired regions is therefore not a forced migration, but an opportunity to simplify. Customers can continue using paired regions where business requirements demand it, while selectively modernizing other workloads to take advantage of platform-managed zone resilience. What’s coming up next for resilience in Azure? Resilience is evolving from static guidance to continuous, workload-aware execution. A multi-region strategy isn’t only about recovery; it’s also a practical hedge against regional capacity constraints (regions have physical limits within a latency boundary, so growth can eventually hit caps). Resiliency agent in Azure Copilot (preview) helps you spot missing resiliency coverage—such as zone alignment gaps or missing backup/DR—and provides automated guidance (including scripts) to remediate issues, configure Azure Backup and Azure Site Recovery, and define recovery drills. Resiliency in Azure brings zone resiliency, high availability, backup, DR, and ransomware protection together into a unified experience within Azure Copilot, enabling teams to set resiliency goals, receive proactive recommendations, and view service‑group insights via Azure portal. If you’re looking for service-specific BCDR and replication guidance, use these authoritative starting points: Cloud Adoption Framework (CAF) – Landing zone design area (BCDR): guidance to define platform DR requirements (RTO/RPO), data residency considerations, and operational readiness as part of landing zone design. Azure Well-Architected Framework (WAF) – Disaster recovery strategies: guidance for structuring, testing, and operating DR plans aligned to recovery targets, with links to companion DR planning resources. WAF design guide – Regions & Availability Zones: how to choose between zone- vs region-based approaches and understand reliability/cost/performance tradeoffs. Azure service reliability guides: service-by-service reliability/replication behavior and customer responsibilities. Non‑paired multi‑region configurations: examples of supported multi-region approaches when regions aren’t paired. Validate feasibility before you design: confirm service/SKU/zone availability in both regions. Next step: Explore Azure Essentials for guidance and tools to build secure, resilient, cost-efficient Azure projects. To see how shared responsibility and Azure Essentials come together in practice, read Resiliency in the cloud—empowered by shared responsibility and Azure Essentials and How to design reliable, resilient, and recoverable workloads on Azure on the Microsoft Azure Blog. For expert-led, outcome-based engagements to strengthen resiliency and operational readiness, Microsoft Unified provides end-to-end support across the Microsoft cloud. To move from guidance to execution, start your project with experts and investments through Azure Accelerate. Related Resources Architecture strategies for using Availability Zones and Region High Availability Architecture strategies for highly available multi-region design Disaster Recovery Architecture strategies for designing a Disaster Recovery strategy Multi-Region solutions in nonpaired Regions Develop a disaster recovery plan for multi-region deployments Azure Regions and Services Azure region pairs and nonpaired regions Reliability guides for Azure servicesAzure Best Practices delivered to machines anywhere with new Azure Arc and Automanage integration.
Tired of manually onboarding and configuring Azure services for your Arc-enabled servers? With Azure Automanage Machine Best Practices, you can point, click, set, and forget to extend Azure security, monitoring, and governance services to servers anywhere.Announcing Landing Zone Accelerator for Azure Arc-enabled SQL Managed Instance
With both Azure Arc-enabled servers and Kubernetes Landing Zone Accelerators already generally available, today we're launching the Azure Arc-enabled SQL Managed Instance landing zone accelerator within the Azure Cloud Adoption Framework.
Give us your thoughts on running Kubernetes anywhere for a chance to win a $300 USD gift card!
Do you work with Kubernetes? Are you interested in improving Kubernetes experience across hybrid and multicloud environments? Take the survey below for a chance to win a $300 USD virtual gift card! Must be 18 or older. Survey ends on May 10, 2023.Challenges of Containerized App Portability in Kubernetes
Introduction As organizations embrace containerization and Kubernetes for their applications, the need for seamless portability across the Kubernetes ecosystem coupled with cloud object storage and local persistence has become a pressing concern. In this blog post, we will dive into the core problem and dissect the complex challenges that customers face in achieving containerized app portability. Challenges Local Persistence and High Availability Local persistence is crucial, but ensuring highly available Kubernetes volumes that can tolerate hardware failures presents a challenge. Organizations need a robust solution to maintain continuous operation and data integrity. Coordinating Consistency Across Apps Coordinating data consistency across all edge applications sharing data is imperative. Ensuring that data changes are propagated uniformly and reliably is a significant challenge in a distributed and dynamic Kubernetes environment. Once cloud storage is involved in your data management strategy, consistency handling between edge data bound for cloud processing becomes even more challenging. Data Upload at the Edge A suite of containerized apps deployed at the edge needs to upload data to cloud storage, introducing challenges related to data transfer, synchronization, and efficient utilization of bandwidth. Avoiding Cloud Storage API Coding for Every App It is not feasible for every app in the suite to code directly to the Cloud Storage API. Organizations need solutions that abstract this complexity, providing a unified interface for different applications without compromising on functionality. Disconnect/Reconnect Logic The need for disconnect/reconnect logic to handle network disconnections introduces an additional layer of complexity. Applications must seamlessly adapt to network disruptions, ensuring uninterrupted operation and data flow. Shared Filesystem Capability Implementing shared filesystem capability on top of high availability volumes is essential. Achieving this requires careful orchestration to avoid data inconsistencies and conflicts in a distributed environment. Addressing the Challenges Robust High-Availability Strategies Implement robust strategies for local persistence and high availability within Kubernetes clusters, minimizing the impact of compute hardware failures and maintaining continuous operations. Unified Filesystem Abstraction Ensures consistency across applications without compromising on the benefits of distributed storage. Edge-Focused Data Solutions Explore solutions tailored for edge computing that efficiently manage data upload, synchronization, and bandwidth utilization, ensuring optimal performance in edge environments. Smart Network Handling Implement intelligent disconnect/reconnect logic that enables applications to handle network disruptions gracefully. This ensures uninterrupted operation and minimizes the impact of transient network issues. If you choose to cloud-enable your application, you must consider cloud unavailability. Infrastructure Capability Differences between Kubernetes Environments Application developers must be aware of the inherited advertised capabilities of differing cloud and edge environments which are often not homogenous. Taking an application from Dev/Test environment to a different Production environment typically requires additional deployment customization. Conclusion In the landscape of containerized applications across Kubernetes, achieving portability across the ecosystem while leveraging cloud object storage and local persistence is a multifaceted challenge. By understanding and addressing the specific challenges related to high availability, shared filesystems, data upload, and network handling, organizations can pave the way for a more efficient and resilient containerized app deployment. As the industry continues to evolve, staying up to date on emerging solutions and best practices is essential for navigating the complexities of Kubernetes and ensuring a portable and robust application ecosystem. Check back shortly for a follow-on blog post talking about how you can build deployments that address some of these challenges.Launching the Arc Jumpstart Newsletter: October 2024 Edition
We are excited to kick off this monthly newsletter, where you can get the latest updates on everything happening in the Arc Jumpstart realm. Whether you are new to the community or a regular Jumpstart contributor, this newsletter will keep you informed about new releases, key events, and opportunities to get involved in within the Azure Adaptive Cloud ecosystem. Check back each month for new ways to connect, share your experiences, and learn from others in the Adaptive Cloud community.
Announcing the Azure Arc ISV Partner Program at Ignite
Empowering Partners and Enhancing Customer Experience We are thrilled to introduce the newly launched Azure Arc ISV Partner Program at Ignite! This innovative and growing ecosystem partner program allows them to publish offers on the Azure Marketplace that can be deployed to Arc-enabled Kubernetes clusters. Customers can now access validated, enterprise-grade applications and tools to enhance their Azure Arc development, while ISVs benefit from a deeper integration with Azure Arc services and access to the Arc enabled customer base. All marketplace images have been validated across the Azure Arc platform with the support of both Microsoft and partner teams. With the solutions each partner has made available on the Azure marketplace, the integration with Azure Arc offers central governance to build robust applications with consistent security and reliability for any hybrid deployments. What is Azure Arc? Azure Arc is a platform that extends Azure to datacenters, on-premises, edge, or even multi-cloud environments. It simplifies governance and management by delivering the consistency of the Azure platform. The ability to create offerings for Azure Arc in the marketplace is a significant benefit to our partners, allowing them to integrate with Azure services and tools and access a large and diverse customer base. Azure Arc also provides validated applications for customers to manage their Kubernetes clusters on our platform. Edge developers leverage the open-source community to build their enterprise applications, and we aim to provide them with a one-stop shop in Azure Marketplace, offering a choice of Kubernetes-based building blocks needed to develop their applications. Meet our partners With our Ignite launch, we have built the foundation of an ecosystem that is designed to bring the best capabilities and innovations to our marketplace, focused on leading building block categories: databases, big data/analytics, and messaging. We are excited to introduce our esteemed partners, (CloudCasa, MongoDB, Redis, MinIO, DataStax) who have Arc enabled their application and will now be available on the Azure Marketplace. Here’s a closer look at their offerings: CloudCasa CloudCasa is a leading provider of Kubernetes backup and recovery solutions. By Arc-enabling their application, CloudCasa offers robust, secure, and easy-to-use backup services for Kubernetes, ensuring the protection and availability of critical data. With CloudCasa, your Arc enabled Kubernetes deployments across hybrid environments are fully protected, ensure that your data is safe and recoverable, no matter the scenario. CloudCasa’s integration with Azure Arc offers three key components: handling persistent volume with or without CSI snapshots, unified management and monitoring across environments, and disaster recovery and migration for AKS hybrid. One-way CloudCasa manages persistent storage is that it natively integrates with Container Storage Interface snapshots, ensuring that all your persistent volumes can be captured and protected without interrupting your workloads. CloudCasa also provides a powerful disaster recovery and migration solution. For AKS on Azure Stack HCI, this means you can confidently deploy hybrid and edge clusters, knowing that you have a trusted solution to recover from any disaster, or even perform seamless migrations from edge to cloud or vice versa. To explore CloudCasa’s full capabilities for Azure Arc-enabled Kubernetes clusters, visit the CloudCasa Marketplace listing for Azure Arc or find out more at cloudcasa.io. For personalized assistance, feel free to contact casa@cloudcasa.io. DataStax DataStax is a leading provider of Gen AI solutions for AI developers. With DataStax HCD (Hyper-Converged Database), businesses can harness the power of Apache Cassandra, the highly scalable and resilient NoSQL database, to manage large volumes of structured and vector data with ease. By Arc-enabling their applications, DataStax HCD offers users a “single pane of glass” for streamlined deployment, monitoring, and lifecycle management of their entire infrastructure. Ensuring consistent operations across on-premises, Azure, and multi-cloud environments makes Azure with HCD an ideal choice for mission-critical applications. The combination of Azure Arc central governance and Mission Control, DataStax’s operations platform, on HCD will allow for provisioning of resources for on-premises and on the cloud. HCD brings to Azure Arc database management and the ability to support workloads and AI systems at scale with no single point of failure. DataStax HCD brings three key benefits to Azure Arc: data replication and distribution, node repair, and vector search capabilities to enhance your enterprise data workloads. To learn more about the full capabilities of DataStax HCD, please visit the DataStax HCD for Azure Arc or find out more on the HCD product page. MongoDB MongoDB Enterprise Advanced (EA) empowers customers to securely self-manage their MongoDB deployments on-premises or in hybrid environments, driving operational efficiency, performance, and control to meet specific infrastructure needs. Now with Arc-enablement, MongoDB EA allows developers to build, scale, and innovate faster by providing a robust and dynamic database solution across a multitude of environments. MongoDB’s document data model is intuitive and powerful, and it can easily handle a variety of data types and use cases efficiently. MongoDB EA includes advanced automation, reliable backups, monitoring capabilities, updating deployments, and integrating with various Kubernetes services. The MongoDB integration with Azure Arc provides three key benefits: support for multi-Kubernetes cluster deployments, centralized provisioning through the Azure portal, and leveraging the resilience of Kubernetes deployments. As Azure Arc provides centralized management of Kubernetes environments across a multitude of environments, MongoDB EA adds value with databases that can run across multiple Kubernetes clusters. To explore MongoDB EA on Azure Marketplace for Azure Arc - and to learn more about the full potential of this offering - please visit MongoDB Enterprise Advanced for Azure Arc. For licensing inquiries and to learn more about MongoDB Enterprise Advanced, please visit MongoDB's website. Redis Redis Software, an enterprise-grade, real-time data platform, offers an in-memory data structure store used as a cache, vector database, document database, streaming engine, and message broker. With its Arc-enabled application, Redis Software provides ultra-fast data access, real-time analytics, and seamless scalability. This makes Redis Software ideal for applications requiring high performance and low latency. Integrating with Azure Arc allows users to deploy Redis workloads across on-premises, Cloud and hybrid infrastructure. The benefits Redis Software brings to Azure Arc are support multi-core deployments, Active-Active geo-distribution, data tiering, high-availability with seamless failover and multiple level of on-disk persistence. As it is integrated with Arc, these Redis instances are located on-premises or on the cloud and can be managed centrally on the Azure portal. To explore Redis Software on the Azure Marketplace for Azure Arc, please visit Redis Software for Kubernetes for Azure Arc. You can learn more about licensing inquiries at Redis Software. MinIO MinIO AIStor is the standard for building large scale AI data infrastructure. It is a software-defined, S3 compatible object store that is optimized for the private cloud but will run anywhere - from the public cloud to the edge. Enterprises use AIStor to deliver against artificial intelligence, machine learning, analytics, application, backup and archival workloads - all from a single platform. It was built for the cloud operating model, so it is native to the technologies and architectures that define the cloud, such as: containerization, orchestration with Kubernetes, microservices and multi-tenancy. By Arc-enabling their application, MinIO ensures that Azure users can experience the unmatched scalability, robust security, and lightning-fast storage performance that has made MinIO the most widely integrated object store in the market today. Users can now run these hybrid or multi-cloud deployments on Azure Arc and manage them in a single pane of glass on the Azure portal. To deploy and learn more about MinIO AIStor on Azure Arc, please visit MinIO AIStor for Azure Arc here. For further information on MinIO AIStor for Azure Arc, please visit MinIO | AI Storage is Object Storage. Become an Arc Enabled Partner These partners have collaborated with Microsoft to join our ISV ecosystem, providing resilient and scalable applications readily accessible for our Azure Arc customers via the Azure Marketplace. Joining forces with Microsoft enables partners to stay ahead of the technological curve, strengthen customer relationships, and contribute to transformative digital changes across industries. We look forward to expanding this program to include more ISVs, enhancing the experience for customers using Arc enabled Kubernetes clusters. As we continue to expand our Azure Arc ISV Partner Program, stay tuned for more blogs on the new partners being published to the Azure Marketplace. To reach out and learn more about the Azure Arc ISV Partner Program, please feel free to reach out to us at https://aka.ms/AzureArcISV.
