ArcGIS Enterprise has come a long way since the original 2018 “ArcGIS Enterprise in the cloud” blog post. Cloud computing has evolved rapidly, and organizations are increasingly blending on-premises systems with cloud infrastructure to achieve the best of both worlds. This blog will update the ArcGIS Enterprise cloud story focusing on the Windows and Linux deployments as well as talk about current trends.
ArcGIS Enterprise: On-Premises vs Cloud vs SaaS – Finding the Right Mix
Deploying ArcGIS Enterprise on Windows and Linux “in the cloud” essentially means running the software on virtual infrastructure provided by a cloud vendor instead of physical servers on-premises. This approach falls under Infrastructure as a Service (IaaS), where you provision virtual machines, storage, and networking in the cloud and install ArcGIS Enterprise on them. This is distinct from Software as a Service (SaaS) like ArcGIS Online, where Esri hosts and manages everything for you.
In practice, ArcGIS Enterprise is supported on any cloud platform that meets its system requirements including all major public and private clouds (AWS, Azure, Google Cloud, etc.). ArcGIS Enterprise doesn’t require any modification to run in different environments; an ArcGIS Enterprise on the cloud has the same features and tools as a deployment on prem. The reason why is that cloud deployments may offer operational differences, especially if we’re considering different cloud stores.
Running in the cloud can offer considerable business and technical advantages. Cloud platforms provide on-demand scalability (the ability to easily add or remove computing resources to handle peak GIS workloads, such as seasonal surges), high reliability and disaster recovery options (data centers with built-in redundancy across availability zones and robust backup services), and a shift from an upfront capital expense model to a more flexible operational expense. You don’t have to buy and maintain physical servers, the cloud vendor takes care of hardware failures, power, cooling, and expansion, giving you time to focus on the software and data.
Additionally, Cloud providers like Google Cloud, AWS, and Microsoft Azure have established global regions to ensure high availability, low latency, and disaster recovery capabilities. These regions are geographically distinct areas where cloud providers house their infrastructure, enabling users to deploy ArcGIS Enterprise and other resources closer to their end-users, reducing latency and improving application performance. Each region consists of multiple data centers that operate independently, and multiple availability zones (AZs) within a region are interconnected with high-speed, low-latency links. This setup allows for redundancy and fault isolation, making it possible to stay online even if one zone has issues.
It’s clear why many enterprises are embracing cloud deployments of ArcGIS Enterprise but, it’s important to go beyond just moving servers and take advantage of what the cloud offers.
Cloud Deployment Patterns: From Lift-and-Shift to Cloud-Optimized
Over the past few years, we have seen thousands of organizations migrate from on-premises deployments or ArcGIS Enterprise to the cloud. There’s a spectrum of approaches between a basic “lift-and-shift” and a fully cloud-optimized architecture.
In a lift-and-shift migration, you take an existing ArcGIS Enterprise deployment (Portal for ArcGIS, ArcGIS Server, ArcGIS Data Store, etc. on a set of machines) and replicate it in the cloud with minimal changes. The software’s behavior remains the same after moving to the cloud but now it runs on cloud infrastructure, immediately gaining benefits like eliminated hardware procurement and easier infrastructure maintenance. This approach is often the fastest path to the cloud and can be a great first step.
However, simply moving to virtual machines is only part of the story. Cloud providers offer cloud services that can improve and simplify your ArcGIS Enterprise deployment further. A cloud-optimized ArcGIS Enterprise architecture leverages these services (platform-as-a-service, or PaaS offerings) for better scalability and resiliency.
Common examples include using cloud storage (e.g., Amazon S3, Azure Blob Storage) to support the hosting server’s object store or as a cache directory for map and image services, or using a database service offering to host a relational database instead of installing and managing a RDMBS on a VM in the cloud. In fact, many organizations today host their enterprise geodatabases using database service offerings.
Today, in 2026, ArcGIS Enterprise on Windows/Linux evolved to integrate in new ways and more deeply with cloud services offered from AWS and Azure. A prime example is the management of ArcGIS Enterprise’s configuration and content storage. In the past, a multi-machine deployment needed a shared network file system for the portal’s content directory and ArcGIS Server’s configuration store and directories. This was often a single point of failure if not set up carefully.
Over recent releases, ArcGIS Enterprise introduced support for placing these on cloud storage, eliminating the need for a dedicated file server. As of ArcGIS Enterprise 12.0, you can configure all of an ArcGIS Enterprise deployment’s inherent file storage on cloud services when running in AWS or Azure – including the ArcGIS Server directories (for caches, job results, output, etc.). In the past, these had to be on a physical network share; now they can be configured to use cloud services in AWS or Azure.
Most organizations find a balance along this spectrum. You might start with a basic lift-and-shift, then progressively integrate cloud services. ArcGIS Enterprise provides flexibility to allow this incremental approach. For instance, you can migrate the caches from your map or image services to cloud storage (for better scalability) while still using your existing database on a VM, and then later move that data to a database service when ready. The key is that ArcGIS Enterprise is cloud-agnostic and modular: you can plug in cloud infrastructure at the points that make sense for your organization.
A major trend is using a mix of on-premises and cloud deployments. “Hybrid cloud” in this context means you maintain some ArcGIS Enterprise deployments on-premises and others in one or more clouds, with intentional workflows connecting them. For example, an organization might keep an ArcGIS Enterprise instance on-prem for internal use (perhaps because of sensitive data or integration with legacy systems) and another ArcGIS Enterprise in the cloud to serve external users or as a scalable front-end for public applications. These two can be run as separate but connected systems.
One way to connect two ArcGIS Enterprise deployments is through distributed collaboration, which allows you to share content (maps, layers, etc.) between them in a controlled manner. Using collaboration, you could author data on your internal Enterprise and periodically push updates to the cloud-hosted Enterprise that powers a public site, keeping the environments segmented but in sync where needed. Another common hybrid pattern is using the cloud as a disaster recovery or surge capacity site. For instance, your primary ArcGIS Enterprise is on-premises, but you have a standby deployment in the cloud that is updated periodically (using the WebGISDR backup/restore tools). In an outage of the on-prem system, you can fail over to the cloud deployment. Or, if you have a sudden spike in demand beyond what your on-prem servers can handle, you could temporarily redirect users to a cloud deployment. Thanks to automation (discussed below), you can now quickly and easily set up these environments whenever needed, making rapid deployment a straightforward process.
Yet another flavor of hybrid is multi-cloud or cross-cloud deployments. Because ArcGIS Enterprise is not tied to any single cloud provider, some organizations choose to deploy on multiple clouds to improve resilience or avoid vendor lock-in. For example, you might run parallel environments on AWS and Azure and use traffic management to switch if one has an issue. While this is more complex and less common, it underscores that you have flexibility. ArcGIS Enterprise can run in whatever infrastructure makes sense, and you can move or replicate it as your cloud strategy evolves.
Leveraging Cloud Options with ArcGIS Enterprise 12.0
Deploying ArcGIS Enterprise 12.0 in a cloud environment presents new opportunities for optimizing how system directories are managed. Traditionally, server directories, the portal content directory, and the configuration store were kept on file shares. However, recent advancements now allow administrators to use cloud storage services, such as Amazon S3 and Azure Blob Storage, instead of traditional file system storage. In addition, distributed services like messaging platforms and NoSQL databases can now be used to enhance the deployment. For example, a messaging service such as Amazon SQS or Azure Service Bus enables communication between different parts of the system, helping coordinate tasks and data exchange efficiently.
Similarly, a NoSQL database service like Amazon DynamoDB or Azure Cosmos DB is used to reliably store configuration and job state information in the cloud, supporting asynchronous workflows (where tasks are managed independently and processed as resources become available). By leveraging these cloud storage and distributed services, organizations can achieve greater scalability, improved reliability, and easier disaster recovery for their ArcGIS Enterprise deployments, making it possible to handle larger workloads and respond quickly to changing business needs.
Currently, with ArcGIS Enterprise 12.0, the option to configure server directories with cloud storage is available for:
- ArcGIS GIS Server
- ArcGIS Image Server
- ArcGIS Knowledge Server
- ArcGIS Workflow Manager Server
Article Discussion: