Following is the recommended architecture for deploying ArcGIS software that is intended to work with imagery in the cloud. Amazon Web Services (AWS) is used in the examples, but a similar deployment would work in most cloud environments.
Your ArcGIS Enterprise portal is typically connected to an ArcGIS Server (they can be combined, but they are typically kept separate). The GIS server has a data store that can be used for features.
This is then federated with your analytical servers—ArcGIS Image Server, in this case. If you intend to use ArcGIS Image Server, both to serve dynamic image services and to perform raster analytics, it’s recommended to use two separate servers or server clusters, one for dynamic imagery and a separate one for raster analytics. Raster analytics will consume every resource it can to maximize processing capacity. If you use the same server to serve dynamic image services, performance of the image services will suffer. When a user tries to pan in an image service, for example, the server may be occupied with processing tasks and unable to fulfill the request.
Additionally, you can connect ArcGIS Notebook Server or ArcGIS Pro. These can be installed on dedicated virtual servers (EC2 instances in the case of Amazon) that can be destroyed when you’re done using them (meaning you’re no longer paying for them).
You can also connect to different storage options. This could include registering a raster store in cloud storage or directly connecting to an AWS S3 bucket as a source for your imagery and rasters. You would typically use an AWS Relational Database Service (RDS) as an enterprise geodatabase (it's recommended that you do not use the enterprise geodatabase inside the portal; make it external instead). The infrastructure also requires a small file store for certain temporary files.
Note:
See this Esri Community blog post for information about options for deploying desktops in the cloud.
Prerequisites
Before deploying in the cloud, a number of prerequisites must be met. Using AWS as an example, you need the following:
- An Amazon account with full access to EC2 and other resources
- A valid domain name for your site
- A TLS (SSL) certificate for your domain, obtained from a certifying authority
- An elastic IP address that you will associate with the EC2 instance (you must map your domain name to the elastic IP address).
- License files for Portal for ArcGIS, ArcGIS Server, and ArcGIS Image Server
- If the Amazon account is new, the following actions are recommended:
- Create a virtual private cloud with an elastic IP and key pair.
- Create an elastic load balancer.
- Create S3 buckets.
- Configure the security groups for SSH and RDP access.
- Note the VPC ID, the SiteEIPAllocationID for the elastic IP, and the key pair for reference.
Recommended deployment specifications
For more information about different options for installing ArcGIS Enterprise in the cloud, consult resources for Amazon Web Services and Microsoft Azure.
The following are recommended specifications for deploying ArcGIS Enterprise with ArcGIS Image Server in the cloud using Amazon Web Services:
- ArcGIS Enterprise
| Component | AWS specification |
|---|---|
Virtual server | M5d.2xlarge (1 instance) |
Note:
It's recommended that you use EC2 M5d instances because M5d servers have an ephemeral drive that is best suited for caching, which can improve performance.
- ArcGIS Image Server (image hosting)
| Component | AWS specification |
|---|---|
Virtual servers | M5d.2xlarge (2 instances in autoscaling mode) |
RDS (for enterprise geodatabase) | db.m4.xlarge (1 instance) (Use a db.r4.xlarge for mosaic datasets larger than 20 GB.) |
Elastic load balancer |
- ArcGIS Image Server (raster analytics)
| Component | AWS specification |
|---|---|
Virtual servers | M5d.2xlarge (2 instances in autoscaling mode) |
RDS (for enterprise geodatabase) | Use the RDS setup with ArcGIS Image Server configured for image hosting. |
Elastic load balancer |
Recommended architecture for ArcGIS Enterprise and ArcGIS Image Server
The following diagram shows the recommended infrastructure for ArcGIS Enterprise with ArcGIS Image Server in the cloud environment. (Also, refer to information about the base ArcGIS Enterprise deployment.)
Recommended architecture for stand-alone ArcGIS Image Server
The following diagram shows the recommended infrastructure for a stand-alone ArcGIS Image Server and ArcGIS Pro 2.4 and later deployment in the cloud environment.
Typically, your ArcGIS Image Server is siloed and configured for autoscaling. This means you’ll have multiple machines, independent of each other, with a load balancer in front of them that distributes the load from dynamic image services among the machines. These are then connected to an RDS (for your enterprise geodatabase), file stores, and ArcGIS Pro. (If required, you can also use a file geodatabase instead of an enterprise geodatabase.)
Note:
See this Esri Community blog post for information about options for deploying desktops in the cloud.
Prerequisites
Before deploying in the cloud, a number of prerequisites must be met. Using AWS as an example, you need the following:
- An Amazon account with full access to EC2 and other resources
- A valid domain name for your site
- A TLS (SSL) certificate for your domain, obtained from a certifying authority
- An elastic IP address that you will associate with the EC2 instance (you must map your domain name to the elastic IP address).
- License files for ArcGIS Image Server
- If the Amazon account is new, the following actions are recommended:
- Create a virtual private cloud with an elastic IP and key pair.
- Create an elastic load balancer.
- Create S3 buckets.
- Configure the security groups for SSH and RDP access.
- Note the VPC ID, the SiteEIPAllocationID for the elastic IP, and the key pair for reference.
Recommended deployment specifications
The following are recommended specifications for deploying a stand-alone ArcGIS Image Server in the cloud using Amazon Web Services:
- Stand-alone ArcGIS Image Server
| Component | AWS specification |
|---|---|
Virtual servers | M5d.2xlarge (2 instances in autoscaling mode) |
RDS (for enterprise geodatabase) | db.m4.xlarge (1 instance) (Use a db.r4.xlarge for mosaic datasets larger than 20 GB.) |
Elastic load balancer |
Note:
It's recommended that you use EC2 M5d instances because M5d servers have an ephemeral drive that is best suited for caching, which can improve performance.
Dedicated or shared instances
As of ArcGIS 10.7.1, you can create dynamic image services using either dedicated or shared instances. Understanding the difference is important as you scale out the machine with more services.
When you create a service using dedicated instances (the pre-10.7.1 method), you define the minimum and maximum number of processes that are dedicated to each service. This can present a scaling problem if, for example, you have 100 services and you’ve allocated 10 processes to each. You could end up with 1,000 processes running on your server, each of which is allocated some memory, resulting in the machine running out of resources. Image services using dedicated instances can be published using ArcGIS Pro, ArcMap, or the ArcGIS Server Administration API.
Shared instances create a pool of processes that are running for any number of services. Whenever someone makes a request, a process is taken from the pool to fulfill the request and kept in memory until it’s not being used, at which point it's thrown out, and replaced by another process. Shared instances have the advantage of being more scalable, but the drawback is that the first time a request is made to the server, there’s a lag (approximately 12 seconds if you’re using an enterprise geodatabase). Image services using shared instances can be published using ArcGIS Pro or the ArcGIS Server Administration API.
For a service that’s continuously used or needs fast startup, it’s better to use a dedicated instance. For services that are occasionally used, it's better to used shared instances so that more services can be put on a single machine.
File or enterprise geodatabases
For small mosaic datasets, a file geodatabase is satisfactory, but for large mosaic datasets (more than 100,000 records), an enterprise geodatabase is recommended.
When using an enterprise geodatabase, an RDS instance in AWS or SQL Server in Azure is recommended. While your ArcGIS Enterprise portal has an enterprise geodatabase, it’s not recommended for mosaic datasets due to issues setting up the required security between machines and possible scaling issues as the database gets larger.
It’s possible to use a file geodatabase with a file share, but it doesn’t scale well and is not recommended. A file geodatabase frequently interacts with other files—every time you pan and zoom, it checks the database, which is partially stored in memory, and also references a file on disk that is shared with another machine and must be checked, for example, to see if anything changed on it. These small checks can accumulate, and performance suffers with large mosaic datasets. If the file geodatabase is stored on an ephemeral drive (which is not shared with other machines), these file checks are cached by the operating system and are negligible.
The recommendation when using a file geodatabase is to copy it from BLOB storage to the ephemeral disk. This is especially well suited when you’re standing up a siloed stand-alone ArcGIS Image Server, because as the machine stands up, you can specify what it should do before it starts. In that case, you can zip up your mosaic dataset and put it into storage. Then, as the server stands up, it copies the zipped mosaic dataset to the fast ephemeral disk next to the CPU and starts up that server. This takes a couple of minutes, but afterward you can effectively use a file geodatabase.