Logical reference architecture

This logical view of the reference architecture defines the individual software components in each region, how they are separated or combined, and the key interactions between them.

Learn more about diagramming resources for ArcGIS systems.

Software components

The design consists of two structurally identical ArcGIS Enterprise deployments, one acting as the primary and one acting as the warm standby, each in a separate AWS region. In the scenario used here, the primary deployment is in a US-East region and the standby site is in a US-West region.

Each region contains the same set of components:

• A base ArcGIS Enterprise deployment, built on Amazon EC2 instances, including:

  • Portal for ArcGIS, which serves as the entry point for users and as 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.
• An additional ArcGIS Server site configured with the GIS Server role and federated with the portal, illustrating how additional server roles participate in the replicated design.
• An Application Load Balancer (ALB) providing the HTTPS entry point for the region. The ALB terminates TLS using a certificate issued for the organization’s public domain and routes requests to a target group for each ArcGIS component, so load balancing and reverse proxy responsibilities sit in front of the ArcGIS tier.

• Amazon S3 storage serving three separate purposes within the region. Treating these as distinct stores matters, because they are protected by different mechanisms:

  • A folder in an S3 bucket registered with the hosting server as the ArcGIS Enterprise object store, in place of an ArcGIS Data Store object store. This holds live layer data such as hosted scene layers and 3D tile layers.
  • A bucket used as the destination for WebGIS DR backups.
  • Optionally, storage for the ArcGIS Server configuration store, used together with Amazon DynamoDB, when a cloud-native configuration store is preferred over a file share.

Two components span both regions and are what make the pair of deployments behave as a single logical system:

• Amazon Route 53 provides DNS for the system through two kinds of hosted zones:

  • A single public hosted zone that determines which region receives traffic from the internet. This zone controls how traffic is routed from clients to one of the two backend systems, and is where a DNS update takes place to shift traffic to the correct backend system.
  • A private hosted zone in each region, using the same domain name as the public hosted zone and associated with that region’s VPC. The private zones are what allow both deployments to be configured with an identical domain name and web context URL while remaining independently resolvable and operable inside their own VPC.

• Cross-region replication between the two S3 buckets, an AWS feature which copies backup artifacts written in the primary region to the bucket in the standby region without manual transfer.

The WebGIS DR tool, included with Portal for ArcGIS, is the mechanism that extracts current deployment state from the primary site to a single backup, which can then be restored to the standby site. It produces a backup of the full ArcGIS Enterprise deployment, including portal items, hosted content, and server configuration, and restores that backup into the standby deployment.

An enterprise identity provider is recommended for a single sign-on (SSO) experience, though not strictly required. Because both deployments are configured identically, the same authentication configuration applies to each. Learn more about ArcGIS authentication models and providers.

Key interactions

The components described above interact with each other in the following ways:

• Client applications reach the active site over HTTPS through a single, stable domain name. Requests resolve through the public hosted zone to the ALB in whichever region is currently designated as active, and the ALB routes each request to the target group for the portal, hosting server, or additional federated server based on the request path. Because the domain name does not change during a recovery, clients and integrated business systems continue to use the same endpoint. Learn more about DNS, naming, and URLs.

• The standby site receives no user traffic while it is inactive, but it must remain reachable. Because the public hosted zone is configured to point to the primary, clients are not directed to it, and it can be administered and restored into without being exposed to normal user traffic. This is what allows backups to be restored into it on an ongoing basis while the primary site continues to serve users. It is important to distinguish this from the standby being unreachable: the network path from clients to the standby region must already exist and be permitted, because a switchover changes only name resolution.

• Clients need open network access to both regions. Shifting DNS does not create connectivity. Routing, firewall rules, security groups, any VPN or AWS Direct Connect paths, and any forward proxy allowlists must permit client access to both regional deployments before a switchover is attempted. If users can reach only the primary region, DNS will resolve to the standby after a failover and connections will still fail. The ArcGIS Enterprise disaster recovery and replication guidance makes the same point: wherever the standby environment is placed, confirm that ArcGIS Enterprise clients can access it when it is needed.

• DNS resolution differs inside and outside a VPC, which is central to the design. When a request originates from an EC2 instance in a VPC associated with a private hosted zone, the resolver first evaluates whether the private hosted zone’s name matches the domain in the request. If there is no match, the request is forwarded to a public DNS resolver. If there is a match, the private hosted zone is searched for a matching record, and if none is found the resolver returns a non-existent domain (NXDOMAIN) rather than falling back to the public resolver. The practical consequence is that a private hosted zone with an overlapping namespace takes full responsibility for resolving every name under that domain inside its VPC.

• ArcGIS components within a region communicate with each other as they would in any base deployment. ArcGIS Server maintains persistent connections to ArcGIS Data Store, the federated GIS Server site communicates with the portal for identity and sharing, and each component is registered with its own ALB target group. Additional detail on interactions and ports is available in the ArcGIS Enterprise product documentation.

• Deployment state flows one direction at a time, from the active site to the standby site. A WebGIS DR backup is created on the primary site’s portal machine and written to the S3 bucket in that same region. Cross-region replication then copies the backup to the bucket in the standby region, where it is restored on a regular schedule into the standby deployment. The standby site therefore reflects the state of the primary site as of the last successfully completed backup and restore cycle.

• Recovery is a DNS operation rather than a rebuild. Shifting a DNS record in the public hosted zone redirects users to the standby site. Because the standby deployment is already installed, configured, and populated, the time to recover is governed primarily by DNS propagation and the record’s time to live (TTL) rather than by provisioning work. See design considerations for the reliability implications of this approach.