Cloud services and providers

ArcGIS users have deployed systems to the cloud for more than a decade, constantly expanding their footprint and taking advantage of cloud resources to enhance their ArcGIS architectures. Today, a broad set of cloud providers offer a wide array of services, capabilities, and systems, which enable end users to build systems that range from simple and focused to complex and highly business critical. Systems can range from rapidly developed, short-lived development systems to systems with a high service-level agreement (SLA) and with strict security requirements and user controls. Use of the cloud can vary widely between organizations and even within an organization, as can architectures that makes use of cloud resources.

A few representative examples of the breadth of cloud deployments include:

• An ArcGIS deployment in AWS, which uses EC2 virtual machines to host ArcGIS Enterprise in a VPC network, with an Application Load Balancer providing ingress for HTTPS requests, storing data in an AWS RDS for PostgreSQL database and using AppStream to provide reliable, rapid rendering of ArcGIS Pro client sessions to end users.
• An ArcGIS deployment in Azure, which uses Azure Virtual Machines, along with Azure SQL, to accomplish a similar deployment goal. This system may also use Azure Virtual Desktop, Azure Application Gateway, and Azure Storage Blob containers to host raster imagery or other files for analysis and rendering.
• A Google Cloud Platform deployment of ArcGIS using Compute Engine virtual machines, a GCP Load Balancer and Cloud SQL for PostgreSQL for hosting data, along with Google Cloud Storage accounts for hosting imagery data.
• A public-facing content provider system, focused on publishing scalable, public-facing map services from an ArcGIS Server deployment, hosted by a managed service provider in their own “private cloud” data center.

These simplified examples show some of the ways that ArcGIS architectures build on cloud services, across the IaaS to PaaS spectrum, and might leverage any of the deployment concepts or patterns discussed in the other sections of this pillar.

Working in the cloud

Implementation and management of cloud-based infrastructure is different from on-premises deployments in several important ways:

• Storage model: Cloud providers offer different storage models, like object storage, serverless databases, data lakes, or virtual file systems that can vary significantly in both performance and cost, and have significantly different architectural considerations from on-premises options.
• Elasticity and pay-for-use cost model: The cloud is generally more elastic and scalable than on-premises resources, allowing administrators to scale a system up based on load observations, and scale down as required. This scalability only applies where workflows allow it, and it is important to consider scaling both vertically and horizontally at any time in response to demand, rather than committing to a specific hardware profile.
• Security: Security in cloud environments requires different considerations. Secure network design is critical, along with the understanding that the system can no longer rely on being “on the private network” as many services are easily accessible from the public internet unless properly secured. Many organizations use a new cloud environment to implement new security controls, approaches or workflows, and cloud systems are often secured using different technologies or approaches than on-premises deployments, with fundamentally different assumptions and architecture inputs.
• Use of additional cloud native services: Cloud providers have created a wide array of easy-to-access services in the SaaS, PaaS and IaaS categories. These services range from serverless compute systems that can run scripts or create APIs to managed databases, storage types, machine learning interfaces or novel compute approaches. Across this array of resources, many interesting services may play a role in the architecture of an Enterprise GIS system, but they should be carefully assessed for cost, functionality, and usability considerations.

Recommendations

Esri works closely with popular cloud providers to ensure our software is compatible with these systems, and that we take advantage of new technology or changes to the system. To provide some more ArcGIS-specific advice around cloud providers, especially as it relates to architecture, the following points apply:

• ArcGIS can be deployed successfully, with sufficient planning, to any cloud environment with a supported OS. ArcGIS doesn’t specifically support (or not support) any cloud provider, our software support is defined at the operating system level, so any cloud provider (public, private or otherwise) that can deploy a supported operating system for the ArcGIS product should be considered a potential deployment environment. Users should be confident that their deployment in this case is supported and likely to be successful. Cloud-native services such as storage providers, databases, networking components or other offerings may not be fully supported unless specifically covered in ArcGIS documentation.
• Support for cloud-native capabilities is nuanced, and can depend on the product, release, and cloud provider. ArcGIS software products support specific cloud PaaS and IaaS capabilities as the demand for these products increases and we identify ways to support them that align to our product strategy. Support may vary across cloud providers, or have specific guidance, so consult the product documentation closely for your anticipated deployment version.
• Esri builds provider-specific tooling for certain cloud providers to further enable automated deployment. Based on customer feedback, Esri has built a set of tools, including Azure Cloud Builder or the ArcGIS Enterprise CloudFormation templates, but these options are by definition provider-specific, and are not intended to be a cross-cloud capability. For most enterprise IT organizations, automation of cloud deployments is a multi-team process, where the ArcGIS architecture fits in to an existing network system or set of configurations. While automation tools can serve as a quick way to deploy software and get familiar with these resources, most final architectures end up deployed using more specific, targeted methods.
• Cloud environments can be as secure, and indeed more secure than most on-premises systems. Many organizations that consider use of cloud resources have security concerns or are worried about how they will be able to secure public cloud resources, and many ArcGIS users and architects share those concerns. Compared to an on-premises system or data center, cloud resources can seem abstract, and default configurations may lead to systems that are more available or more open during development than planned. Cloud environments, however, when properly planned, secured, and managed, can be more secure than on-premises systems and data centers, primarily due to the shared security model of the cloud providers and the increased redundancy and availability of key systems. Cloud environments also often implement new security standards or protocols earlier, and can apply patching for known vulnerabilities more quickly than most on-premises systems, which rely on patching or upgrades to introduce new functionality.
• When deciding between cloud providers, organizational experience is a key factor. When deploying ArcGIS software to the cloud, whether this system is the first cloud deployment for an organization or their fiftieth, the experience of the staff that are involved is an important contributor to success. This means that if your Enterprise IT organization already has significant experience with AWS, it may make sense to propose your ArcGIS Enterprise deployment be based in AWS, rather than Azure. Or if your team has experience automating deployments with Azure DevOps pipelines, it works best to go along with that process so that you can benefit from their experience and best practices.