This decision guide provides an architecture decision framework for shared and dedicated ArcGIS Server instance models.
Select the instance model by workload. Shared and dedicated instances can coexist within the same ArcGIS Server site, with each eligible service assigned according to service characteristics and requirements.
The architecture decision supported by this guide is how each ArcGIS Server service should be configured, whether through the shared instance pool or with dedicated instances. Shared and dedicated instances can coexist within the same site, so most organizations with mixed service requirements will use both. The practical decision is therefore which eligible services belong in the shared pool and which should remain dedicated, based on service eligibility, workload behavior, performance expectations, and operational requirements.
While the configuration can later be changed for a service, the initial decision on which instance type is a meaningful choice that should be made intentionally. The site also includes a default instance type setting which must be set for newly-published services. This decision can be informed by the context provided in this guide.
The decision is typically owned by the solution or platform architect in collaboration with the ArcGIS Server administrator and the application or service owner. Infrastructure, performance, and operations stakeholders should participate when the workload has significant capacity, SLA, cost, or isolation implications.
Confirm the ArcGIS Server version and applicable shared-instance eligibility rules.
Inventory service types, enabled capabilities, and current instance settings.
Establish the workload profile, including request frequency, concurrency, request duration, processing intensity, expected growth, and business criticality, using a lower environment or existing production deployment.
Identify response-time, SLA, resource-isolation, and service-specific tuning requirements.
Establish monitoring data or a baseline that can be used to validate the selected strategy.
ArcGIS Server CPU and memory capacity planning: The selected instance strategy directly influences CPU and memory consumption, affecting overall server sizing and infrastructure requirements.
Shared-pool sizing and dedicated minimum/maximum instance settings: Instance allocation decisions determine how shared pools are configured and how dedicated service capacity is tuned to meet workload demands.
Workload isolation and possible separation into additional ArcGIS Server sites: Services requiring stronger performance isolation, security boundaries, or operational independence may warrant deployment to separate ArcGIS Server sites.
Performance testing, monitoring thresholds, and operational support: Monitoring and performance validation should be aligned with the chosen instance model to ensure services continue to meet operational and user expectations.
Cloud or virtual infrastructure sizing and cost optimization: The balance between shared and dedicated instances impacts infrastructure utilization, scalability, and the overall cost of operating the platform.
Service publishing standards and default instance-type governance: Publishing practices and governance policies should establish consistent guidance for selecting and managing service instance types across the environment.
Future scale-up or scale-out decisions as workload demand changes: Ongoing workload growth and usage trends may require adjustments to instance allocation, server resources, or deployment architecture over time.
Before making a decision, consider the context for each available option.
Services configured to use shared instances use a common pool of compute processes to host and provide access to multiple compatible services. This model conserves memory by avoiding persistent service-specific processes for services that are not actively handling requests. Each shared instance can receive and process requests for any service in the shared pool. The ArcGIS Server process handles forwarding requests to the shared instance pool based on how a service is configured and returns the results to the client making the request.
Shared instances:
Are recommended for compatible services receiving infrequent requests, particularly on sites hosting many services.
Are well-suited to most compatible cached map and image services and other eligible low-demand services.
Provide better memory efficiency for large service catalogs as the memory consumption is limited to the maximum number of shared instances configured.
Allow capacity to be managed through the site-level shared instance pool rather than independent per-service minimum and maximum instance counts.
Support eligible map and image services; compatibility is the first decision gate before workload, performance, or operational factors are evaluated.
Key documentation references include Configure service instance settings and Tune services to meet user needs.
Services configured to use dedicated instances each rely on specific compute processes to service requests. They provide service-specific capacity isolation and allow configuration of minimum and maximum instances per machine for each service.
Dedicated instances:
Are recommended for services receiving constant, heavy, or particularly compute-intensive requests.
Are appropriate where predictable service-specific capacity or fine-grained tuning is required.
Are required when a service or enabled capability is not eligible for the shared instance pool.
Provide stronger service-level workload isolation than a common shared pool.
Can consume significant memory when many lightly used services maintain persistent dedicated processes.
Recommendation: Use shared instances for eligible lower-demand services and dedicated instances for sustained, compute-intensive, critical, or incompatible services. The decision remains a per-service choice between the two supported instance types.
Use the comparison matrix to compare the two instance types at a high level, then apply the scenarios and recommendations to individual services. The shared-versus-dedicated choice is made per eligible service; both instance types can coexist within the same ArcGIS Server site.
| Decision factor | Shared instances | Dedicated instances |
|---|---|---|
| Service eligibility | Eligible map or image services | All workloads, including those not eligible for shared |
| Traffic profile | Use where pooled response-time behavior is acceptable | Use where sustained demand or predictable service-specific capacity is required |
| Processing / request characteristics | Suitable when pooled capacity meets the workload requirement | Use where sustained or long-running work benefits from dedicated capacity |
| Memory efficiency | High for large low-use catalogs | Higher per-service footprint |
| Per-service tuning | Limited | Independent min/max instances |
| Workload isolation | Common pool | Service-specific processes |
| SLA / criticality | Use when pooled behavior meets requirements | Strong fit for critical or SLA-bound services |
| Administrative burden | Lower | Moderate |
| Best fit | Eligible services whose requirements are met by pooled capacity | Services requiring dedicated capacity, tuning, or unsupported shared capabilities |
Use shared instances only after confirming service eligibility and validating that pooled capacity can meet the service’s workload and response-time requirements. Use dedicated instances for services that are incompatible with the shared pool, receive sustained or compute-intensive traffic, require predictable service-specific capacity, or support critical business workflows. In environments with mixed service requirements, assign each service to shared or dedicated instances according to these criteria.
| Scenario | Recommended strategy | Architecture rationale |
|---|---|---|
| Large catalog of lightly used services | Shared instances | Use the shared pool for eligible services to reduce persistent ArcSOC memory consumption and improve resource efficiency. |
| High-volume operational service | Dedicated instances | Use service-specific capacity and instance tuning to support sustained request volume and predictable performance. |
| Business-critical or SLA-bound service | Dedicated instances | Favor predictable service-specific capacity, workload isolation, and independent tuning. |
| Compute-intensive service | Dedicated instances | Isolate resource-intensive processing rather than allowing sustained or expensive requests to consume shared-pool capacity. |
Treat compatibility as the first decision gate. Only supported map and image services can use shared instances.
Use shared or dedicated instance models as appropriate to support the diverse requirements of the service portfolio.
Use shared instances to improve efficiency for eligible, infrequently requested services.
Use dedicated instances where sustained demand, processing intensity, business criticality, or service-specific tuning justifies dedicated capacity.
For dedicated services, minimum and maximum instances are configured per machine. Tune these settings together with available CPU and memory capacity rather than treating instance counts independently of machine resources.
Where an ArcGIS Server site contains materially different workload profiles, evaluate each eligible service individually and use shared or dedicated instances as appropriate.
Ensure the ArcGIS Server site has sufficient CPU capacity for the combined demand from services using the shared pool and services using dedicated instances.
Monitor ArcGIS Server logs and server statistics before and after changing instance allocation.
Reassess the strategy as traffic, capabilities, business criticality, infrastructure, or software versions change.
Remember that a service can experience a cold start when the process needed to serve the request is not already loaded. This can occur with dedicated services when an available instance must be started, and with shared instances when the requested service definition must be loaded into the shared pool.
Use separate ArcGIS Server sites when workload separation is required beyond what service-instance selection provides.
Shared instance performance and utilization can be observed through monitoring of the DynamicMappingHost system service.
Validate the selected instance strategy by monitoring data instead of treating the initial classification as a one-time decision. Review ArcGIS Server statistics, service response times, request duration, error patterns, CPU and memory utilization, and user-facing performance before and after changes. Adjust shared-pool sizing, dedicated instance limits, or workload placement when observed behavior differs from the expected profile.
This pattern assumes that service eligibility has been verified for the applicable ArcGIS Enterprise version. It does not replace workload testing, capacity modeling, or review of service-specific capabilities. Services with specialized extensions, unsupported capabilities, or unique operational requirements should be evaluated individually before changing instance allocation.
Anticipate and accommodate users — ArcGIS Server
Best practices for system architecture — ArcGIS Server