Back to Top

Introduction and overview

This reference architecture represents a replicated, geographically redundant deployment of ArcGIS Enterprise on Linux in Amazon Web Services (AWS). Its primary system is supported by a warm standby system in a second region and kept up to date using the WebGIS DR tool. It is intended for organizations that operate ArcGIS Enterprise in the cloud and need a disaster recovery (DR) approach that limits downtime in the event of a regional failure or other catastrophic event.

Note:

This reference architecture represents an example blueprint for this system type. The design does not reflect the needs of all ArcGIS Enterprise deployments, and it is one of several disaster recovery approaches an organization might choose.

The design pairs two identical ArcGIS Enterprise deployments, one in each of two AWS regions. Only one of the two is reachable from the internet at any given time: DNS determines which site is active, and a scheduled backup and restore cycle keeps the standby site current. Recovery is performed by shifting DNS traffic to the standby site rather than by rebuilding a deployment from scratch.

Note:

This is a disaster recovery design, not a high availability design. The standby site only contains content up to the point of the last successful backup and restore cycle. See the design considerations for a fuller discussion of this tradeoff.

Capabilities

This architecture delivers disaster recovery capabilities for an ArcGIS Enterprise deployment, including:

  • A warm standby deployment in a second, geographically separate AWS region, fully installed and configured rather than provisioned on demand after an outage or disaster event
  • Identical configuration across both deployments, including the same web context URLs and domain name, so that clients and integrated systems do not need to change how they reach the system after a recovery
  • A repeatable backup and restore cycle between the two sites using the WebGIS DR tool, carrying portal items, hosted content, and server configuration from the primary site to the standby site
  • Automated, cross-region replication of backup artifacts so that a backup taken in the primary region is available in the standby region without manual transfer, complemented by a separate replication strategy for stores the backup does not cover, such as the S3 object store
  • A DNS-driven recovery mechanism that shifts user traffic from the primary site to the standby site, with recovery time governed by DNS record time to live (TTL)
  • A workflow that lends itself to scripting and automation, including backups, restores, traffic shifting, and detection of which site is currently active

The scenario used to develop this reference architecture places the primary site in a US East region and the standby site in a US West region, though the design applies to any pair of regions that meets an organization’s data residency and latency requirements.

Software components

This reference architecture is based on ArcGIS Enterprise 11.5 on Linux, deployed to Amazon EC2 instances. The following ArcGIS components are included:

  • Portal for ArcGIS, the entry point for users and the machine from which WebGIS DR backups and restores are run.
  • ArcGIS Server configured as a hosting server.
  • ArcGIS Data Store configured as a relational store for persisting ArcGIS-managed data. In this design the object store is provided by Amazon S3 rather than by ArcGIS Data Store, as described below.
  • An additional ArcGIS Server site configured with the GIS Server role, federated with the portal.
  • The WebGIS DR tool, a utility included with Portal for ArcGIS that creates a backup of a full ArcGIS Enterprise deployment and restores it to another deployment.

The design also depends on the following AWS services:

  • Application Load Balancer (ALB) in each region, providing the HTTPS entry point to the deployment, supporting TLS with a certificate issued for the public domain, and routing requests to target groups for the portal, hosting server, and federated server.
  • Amazon Route 53 for DNS, using a public hosted zone to control which region receives internet traffic and a private hosted zone in each region to allow both deployments to be configured with the same domain name.
  • Amazon S3 in three distinct roles, which are worth keeping separate when planning the design:
    • As the ArcGIS Enterprise object store. A folder in an S3 bucket is registered with the hosting server to act as the object store, in place of an ArcGIS Data Store object store. This is what allows members to publish hosted scene layers and 3D tile layers.
    • As the WebGIS DR backup target, using a bucket in each region with cross-region replication so that backups written in the primary region are copied to the standby region.
    • As part of the ArcGIS Server configuration store, when a cloud-native configuration store is used instead of a file share.
  • Amazon DynamoDB, used together with S3 for the ArcGIS Server configuration store in a cloud-native storage configuration.
  • Amazon EC2 instances hosting the ArcGIS Enterprise components.

The role each component plays and the way they interact is described in the logical reference architecture. A condensed summary of how the design is built and operated is provided in the implementation approach.

Top