The logical reference architecture describes what the system is composed of. This page summarizes how it is built and operated, in the order the work is typically performed. It is a condensed overview intended to convey the shape of the effort and the decisions involved, not a step-by-step procedure.
Authoritative, step-by-step instructions are maintained in the product documentation and in the source material this reference architecture is based on. For the foundational backup and restore workflow, see disaster recovery and replication and the blog post Migrate to a new machine in ArcGIS Enterprise using the WebGIS DR tool. See the ArcGIS Enterprise on AWS documentation for deployment guidance specific to your organization’s chosen deployment method.
The DNS and load balancing foundation is established first, because both ArcGIS Enterprise deployments must be configured with the same domain name from the outset. Retrofitting this after the software is installed is considerably more difficult.
Create an Application Load Balancer in each region. Attach the appropriate TLS certificate for the public domain registered in Route 53 so that each ALB can terminate TLS. A target group is required when creating a load balancer, so create the portal target group at this point. It does not need registered targets yet.
Create the public hosted zone records in Route 53, using a CNAME type pointed at each regional ALB. The recommended approach is a failover routing policy: configure a primary record for the primary region’s ALB, a secondary record for the standby region’s ALB, and a Route 53 health check on the primary. Route 53 answers with the primary record while its health check passes and automatically switches to the secondary record when it fails.
Set the time to live (TTL) to 60 seconds on both records. A short TTL limits how long clients already holding a cached answer continue to be sent to a failed or former endpoint after a switchover.
A manual single-record swap, where one record is edited to point at the standby ALB when a failure is confirmed, is a simpler alternative if automatic switchover is not needed. It cannot be automated, since there is no second record for a health check to fail over to.
Weighted routing, with one record at weight 100 and the other at 0, is also workable as an on/off switch and can be paired with health checks. AWS positions weighted routing for proportional load balancing rather than active-passive failover, so the failover routing policy is the more direct fit here. If weighted routing is used, the weights must stay at 100/0; an intermediate split such as 70/30 would send live traffic to both regions, and the standby is not continuously consistent with the primary.
Create a private hosted zone in each region, using the same domain name as the public hosted zone, and associate it with the VPC that the region’s ALB belongs to. Depending on the organization’s network configuration, existing hosted zones or regional zones may be appropriate. Consult with your organization’s IT department and DNS management to understand options and choose the best approach.
Add a matching record to each private hosted zone. The record should mirror the one in the public hosted zone. The default TTL of 300 seconds and simple routing policy are appropriate here.
The last two steps are what make the rest of the design work. Two private hosted zones sharing a domain name with the public zone allow both regions to host an identically configured ArcGIS Enterprise deployment, and allow the standby deployment to stay operational inside its own VPC so that restores can be performed against it while the primary site serves users.
This is also where the approach differs most from the equivalent on-premises workflow. On-premises migrations commonly use etc/hosts entries on each machine to resolve the shared public URL to a local component. Here, the per-region private hosted zones provide that name resolution at the VPC level instead, so no host file entries are needed on the EC2 instances.
A private hosted zone with an overlapping namespace answers authoritatively for that entire domain within its associated VPC. If other applications in the same VPC depend on names under that domain, add records for them to the private hosted zone as well, or they will stop resolving.
The following is performed identically in both regions, producing two deployments that differ only in which one receives public traffic.
Deploy the base ArcGIS Enterprise deployment software (Portal for ArcGIS, hosting server, and ArcGIS Data Store) to EC2 instances. Assign the instances appropriate VPCs and security groups to enable ingress from that region’s ALB.
Deploy the additional GIS Server site using the same approach. It will be federated with the portal in a later step, once the shared DNS alias is in place.
Create the remaining target groups for the hosting server and the federated server. The portal target group already exists from the ALB creation step. Depending on the system’s logical architecture, one target group may be sufficient.
Register each instance with its corresponding target group, then configure the ALB forwarding rules to route requests to the correct target group. At this point the portal should be reachable from within the VPC through the DNS name defined in the internal Route 53 records.
Set the portal’s system properties to the shared DNS alias rather than to a machine name, so that the deployment identifies itself by the same name in both regions. This means setting privatePortalURL and WebContextURL to the portal URL built on the shared domain name.
Federate the hosting server and the additional GIS Server with the portal. The administrative URL used during federation may differ depending on the level of administrative access configured for the web tier.
When this is complete, both regions hold a fully functional deployment. The one currently answered by the public hosted zone’s primary record is reachable from the internet and acts as the primary site. The other receives no public traffic while it is inactive and acts as the warm standby, though it remains reachable on the network so that it can be administered and restored into.
The WebGIS DR tool requires certain settings to be identical across the two deployments, and the specifics vary by ArcGIS Enterprise version. The portal’s public URL and the service URLs used to federate ArcGIS Server sites are the most significant. Review the compatibility requirements in the disaster recovery and replication documentation for the version you are deploying before running a restore.
Backups need to exist in both regions without an operator moving files between them.
Create an S3 bucket in each region, using names that make the region and purpose obvious, such as a -backup-east and -backup-west convention.
Enable versioning on both buckets. This is a prerequisite for cross-region replication.
Configure replication on the primary region’s bucket, selecting the standby region’s bucket as the destination. The default settings are generally appropriate.
S3 Replication Time Control is available as an option and replicates 99.99% of new objects within 15 minutes. It is worth considering for large deployments with substantial content and tight downtime expectations.
The WebGIS DR backup does not include the object store when the object store is a folder in an S3 bucket. The backup and the object store are two different stores, and only one of them is handled by the tool. The object store therefore needs its own replication strategy.
Replicate the object store bucket to the standby region independently. A scripted copy using the AWS CLI, run on a schedule, keeps the standby region’s object store aligned with the primary. This is separate from, and in addition to, the replication configured on the backup bucket.
Point the WebGIS DR properties file at the backup bucket, not at the object store bucket. With BACKUP_STORE_PROVIDER = AmazonS3, the backup bucket and region are named by the S3_BUCKET and S3_REGION properties, with PORTAL_BACKUP_S3_BUCKET used for portal content. Keeping the backup bucket and the object store bucket clearly distinguished in configuration avoids a situation where the backup appears to succeed while hosted scene layers and 3D tile layers are missing after a restore.
Because the object store and the WebGIS DR backup are replicated by different mechanisms on potentially different schedules, the two can drift apart. Coordinating their timing keeps the standby site internally consistent.
This design restores from a bucket in the standby region, which keeps the restore local. If you instead restore from a bucket in a different region than the target portal, confirm that no VPC endpoint is configured that would prevent the portal from making the outbound requests needed to restore content. This is a straightforward thing to overlook in a cross-region design and it surfaces only at restore time.
With both deployments in place and buckets replicating, the ongoing operational cycle is a backup on the primary site and a restore on the standby site.
Create a backup of the primary site using the WebGIS DR tool, run on the machine where Portal for ArcGIS is installed. Point the properties file at the S3 bucket in the same region as the primary site. Cross-region replication copies the backup to the standby region automatically. The actual step to initiate the backup can be scripted and scheduled using operating system tooling. Consider incremental backups for larger systems to increase speed of availability.
Restore the replicated backup on the standby site, again running the tool on the standby site’s portal machine. Reference the standby region’s local bucket in the restore properties file rather than the primary region’s bucket.
Fail over. If a failover routing policy was configured, this happens automatically once the health check on the primary fails. Point the health check at a meaningful ArcGIS endpoint rather than at the load balancer alone, and set failure thresholds so that a brief network problem does not trigger a switchover. If switchover is manual, an administrator edits the single record or toggles the weighted records once a failure is confirmed. The resulting downtime depends on how quickly the switch happens, by health check or by operator, plus the TTL on the records and, for a partial rather than total outage, how long clients continue reaching the impaired primary before their cached answer expires. See cross-region switchover at the DNS level for the full tradeoffs between these approaches.
How often the backup and restore cycle runs determines how much data could be lost in a disaster, so the schedule is effectively a recovery point objective decision. See design considerations for more on this tradeoff.
If the original primary site is unavailable for an extended period, the direction of the backup and restore cycle needs to be reconsidered so that content created on the newly active site is preserved when the original region is brought back online.
Because the entire cycle consists of tool invocations and API-driven DNS changes, it lends itself to scripting. Automating the backups, restores, the DNS switchover itself where a failover routing policy isn’t already handling that automatically, and the detection of which site is currently active, reduces both the operational burden and the risk of error during an actual disaster.