ArcGIS Enterprise in the Cloud: Deployment Automation Tools and Best Practices

One of the biggest ArcGIS Enterprise advancements in recent years is the availability of automation tools for deploying ArcGIS Enterprise. Gone are the days of manually spinning up each VM, running installers by hand, and clicking through configuration wizards for every environment. Whether you’re deploying on Azure, AWS, or other environments, Esri provides tools (and supports methods) to automate ArcGIS Enterprise installation and configuration.

Quick Links

Automation Tools | New Deployments | Existing Deployments | Frequently Asked Questions

For the major public clouds AWS and Azure, Esri offers specialized deployment utilities that not only install the ArcGIS software but also provision the necessary cloud resources according to best practices. This often makes deploying ArcGIS Enterprise on these clouds easier than on-prem, because a lot of the heavy lifting is handled for you.

Cloud Deployment Automation Tools

• ArcGIS Enterprise Cloud Builder for Microsoft Azure: A graphical wizard (Windows desktop app) that guides you through deploying ArcGIS Enterprise on Azure. You specify the settings (number of machines, their sizes, region, etc., as well as ArcGIS configurations like admin username, license file, and whether to enable high availability), and Cloud Builder will create all the Azure resources and install ArcGIS Enterprise accordingly. It can deploy a base ArcGIS Enterprise (Portal, Server, Data Store, Web Adaptors on IIS VMs or Azure App Service) and even as well as other types of ArcGIS Enterprise servers. Cloud Builder can also export an Azure Resource Manager (ARM) template for you, so you can reuse or customize the deployment in code.
  • Benefit: Very user-friendly; encapsulates Esri’s recommended architecture for Azure. Great for quickly standing up dev, test, or production environments without deep Azure expertise.
• ArcGIS Enterprise Cloud Builder CLI for AWS: A command-line tool for automating deployments on Amazon Web Services. You run it with a JSON configuration or parameters indicating your desired architecture, and it launches the necessary AWS resources (EC2 instances with the appropriate AMIs, load balancers, security groups, etc.) and installs/configures ArcGIS Enterprise. Because it’s CLI, you can integrate it into scripts and pipelines. Esri also provides a web-based UI version on GitHub (the “Cloud Formation Builder” app) for AWS if you prefer a UI.
  • Benefit: Enables repeatable, scriptable deployments on AWS; good for organizations that want infrastructure as code. It uses Esri’s pre-built Amazon Machine Images (AMIs) that have ArcGIS Enterprise components, which speeds up installation.
• ArcGIS Enterprise Cloud Builder for Azure (Artifacts):  Using “Export Automation Artifacts” from Cloud Builder turns a one-off deployment into a fully automatable, repeatable, IaC-friendly deployment workflow. You export ARM templates and scripts, store them in source control, and then integrate them into your CI/CD pipelines achieving consistency, repeatability, and automation best practices.
  • • Benefit: Provides a blueprint‑quality deployment foundation by converting a point‑and‑click Cloud Builder workflow into version‑controlled ARM templates and scripts, making Azure environments easy to reproduce, audit, and evolve within modern DevOps pipelines.
      
• AWS CloudFormation Templates: For more flexibility on AWS, Esri provides a set of CloudFormation template files that define ArcGIS Enterprise deployments in AWS’s native Infrastructure-as-Code language. You can find templates for a single-machine deployment, multi-machine sites that include additional server types, and so on. Using AWS CloudFormation console or AWS CLI, you deploy these templates, and AWS provisions everything as described.
  • Benefit: Allows deep customization and version control of your deployment architecture. You can treat the template as code, modify instance types, subnets, attach additional storage, etc., and deploy consistently across accounts or regions. These templates underpin what the Cloud Builder CLI does, so they are well-tested. Ideal for advanced AWS users who want to integrate ArcGIS Enterprise into a larger IaC framework.
• Chef Cookbooks for ArcGIS: For any environment (on-premises, private cloud, or other public clouds), Esri provides Chef cookbooks scripts using the Chef automation framework that install and configure ArcGIS Enterprise components on VMs. Chef is a popular configuration management tool, and Esri’s cookbooks encapsulate installation steps for the required components of a base deployment allowing you to declare (in code) the state of an ArcGIS Enterprise deployment.
  • Benefit: Highly flexible and not tied to a specific cloud. You can use Chef in AWS, Azure, Google Cloud, or on bare metal. It’s great for standardized multi-machine deployments and can be integrated into enterprise automation workflows.

Regardless of which method you choose, automation brings consistency and speed. For example, instead of manually clicking through setups which can lead to slight differences or errors, you can deploy identical environments in multiple regions or for multiple departments by reusing the same template or script. If something needs to change (say, using a larger instance type), it’s a small edit and re-deploy, rather than a full rebuild from scratch. From a Product Manager perspective, this means faster time to value – spinning up a new ArcGIS Enterprise for a project can be hours or minutes instead of weeks, and it means fewer configuration mistakes that could lead to issues down the line.

Deployment Options: New and Existing Sites

For New Deployments

When setting up ArcGIS Enterprise with Cloud Builder on AWS or Azure, administrators have the flexibility to use their own pre-existing object store or allow Cloud Builder to create one automatically. For more in-depth guidance, check out these resources:

• ArcGIS Enterprise Cloud Builder for AWS
• Deploy ArcGIS Enterprise on Microsoft Azure

For Existing Deployments

If your current deployment relies completely on file storage for both the configuration store and server directories, you’ll need to maintain this setup until a supported migration path is provided in the future ArcGIS Enterprise release.It’s worth noting that automation isn’t just for initial deployment. Many of these tools can assist with upgrades and expansions as well. For instance, you could use Cloud Builder to add another federated server to an existing site, or use Chef scripts to upgrade components in place by adjusting their version and rerunning the cookbook (with proper care and testing).

Automation scripts can also be part of your disaster recovery plan, the same template that deploys production could be used to deploy a new identical environment from backup if needed. This infrastructure-as-code mindset is increasingly part of modern GIS operations. It is essential to recognize that deployment methods must remain consistent throughout the lifecycle of ArcGIS Enterprise. The approach utilized for the initial deployment should be applied during subsequent upgrades; switching strategies are not recommended and highly discouraged. For instance, if ArcGIS Enterprise was originally deployed with Cloud Builder, upgrading with Chef is not supported.

Embracing Hybrid and Maximizing Value

From a business perspective, modernizing ArcGIS Enterprise in the cloud is about delivering more with less friction. It’s not just a tech migration, but an opportunity to improve how GIS services are delivered to users. Here are a few key considerations and trends:

• Efficiency through Automation: As described, automating deployments leads to faster rollout and consistency. This translates to cost savings in IT labor and more reliable environments. If a team can deploy a new test environment in a day using templates, they’re more likely to test upgrades or new configurations, which leads to higher quality in production. Also, automated deployments often incorporate best practices (security groups, OS settings, etc.) baked in by Esri or your DevOps engineers, which means each new environment is secure and tuned from the start, rather than relying on a checklist that might be missed in manual setup. Overall, less time “keeping the lights on” means more time for delivering GIS capabilities.
• Scalability = Better Performance and User Experience: When demand for your mapping applications grows, a cloud deployment can respond dynamically. For example, if a new analytics service becomes popular and bogs down the system, you could scale out by adding another ArcGIS Server node to the site behind a load balancer. On-premises, you might not have that luxury if no spare server is available or it takes weeks to procure one. In the cloud, it’s typically a matter of running a script or increasing an auto-scaling group’s size. This ensures end-users (like citizens hitting a public-facing map or analysts running heavy workloads) get the performance they need when they need it. It also means you don’t have to permanently run at peak capacity, you can scale in during quiet periods to save costs. Improved performance and reliability directly contribute to user satisfaction with the GIS services, which is a tangible business value (better decisions, more engagement, etc.).
• Cost Management and ROI: There’s often a notion that cloud is cheaper. The reality depends on usage patterns, but cloud certainly allows more granular control of costs. You can match your infrastructure spend to actual usage. Many organizations find that dev/test environments in the cloud can be shut down when not in use (e.g., overnight or on weekends), which is a saving that’s impossible with a physical server that’s been purchased and is always on. Additionally, cloud makes it easier to attribute costs to specific projects or departments (since you can tag resources or have separate subscriptions), which can improve transparency and internal budgeting. From a ROI standpoint, one could justify the cloud move by reducing hardware refresh expenditures and by preventing costly downtime (cloud’s redundancy and easier DR can reduce the risk of an outage that halts operations). A well-architected cloud deployment might also optimize software licensing costs – for example, scaling down the number of ArcGIS Server machines when not needed so you’re not using licenses inefficiently. All of these financial considerations are top-of-mind for product managers and IT directors.
• Hybrid as a Long-Term Strategy: It’s worth reiterating the role of hybrid deployments. Few organizations will flip a switch and move everything to the cloud at once. Instead, many are doing it gradually or keeping a foot in both camps for the foreseeable future. This can actually be the best strategy: use each environment for what it’s best at. Perhaps on-premises is best for your database servers due to large data volumes and internal network speeds, but cloud is best for your web servers due to scalability – you can absolutely connect the two. Or use the cloud for development environments (where the agility is most beneficial) and on-prem for a stable production environment, until you’re confident to cut over production to cloud. ArcGIS Enterprise gives you the choice to architect in this modular way. You can even integrate ArcGIS Online (Esri’s SaaS) with ArcGIS Enterprise in hybrid ways. Modernizing doesn’t mean abandoning what you have, it means augmenting it. Over time, as older systems age out, you might replace them with cloud deployments, but you can do so in a phased approach. This reduces risk and allows stakeholders to get comfortable with the cloud at their own pace.

In wrapping up, it’s important to note that our focus here has been ArcGIS Enterprise on Windows/Linux in IaaS cloud scenarios, essentially a modernization of the traditional deployment model. The capabilities and ease-of-use of ArcGIS Enterprise in the cloud have significantly improved in recent years. Esri is continuing to invest in making ArcGIS Enterprise easier to deploy and manage in any environment. The release of 12.0, with features like cloud storage support for server directories, is a testament to that.

Frequently Asked Questions (FAQs)

• Q: Can I switch my server directories to cloud storage during an upgrade to ArcGIS Server 12.0?
  • A: No, this option is not available during the upgrade. ESRI is currently working on a tool for migration to cloud storage for existing sites.
• Q: Is cloud storage suitable for single-machine sites?
  • A: While most beneficial for multi-machine sites, single-server setups planning future expansion can also take advantage of cloud storage.
• Q: Can a single Amazon S3 instance be used for multiple hosting and federated GIS servers?
  • A: Yes, you can configure Amazon S3 to store server directories for both the hosting server and additional federated GIS servers.
• Q: What’s the best storage option for on-premises deployments?
  • A: Choose storage devices that provide immediate consistency and performance, such as NAS or SAN solutions, rather than distributed file systems like GFS or DFS.
• Q: Upon upgrading to 12.0 and configuring ArcGIS Server for using cloud storage, why is the ‘arcgisssytem’ folder still being used locally at “*\arcgisserver\directories\arcgissystem”?
  • A: ArcSOC processes need local access to certain files to start GIS services and must reside on the machine running the SOC processes.