Amazon OpenSearch Service Idle Cluster Detector
Locate provisioned Amazon OpenSearch (formerly Elasticsearch) domains running multi-node clusters with zero search and indexing queries over 14 days.
1. Detection Scope & Operational Boundaries
Every ArthaOps detector enforces strict epistemic honesty. We clearly separate what can be mathematically proven via agentless telemetry from what requires contextual human judgement.
What This Detector Identifies
- Amazon OpenSearch domains with SearchRate == 0 and IndexingRate == 0 across 14 consecutive days.
- Clusters with JVMMemoryPressure < 15% and CPUUtilization < 2% indicating zero client activity.
- Multi-node data and dedicated master clusters provisioned in staging or sandbox VPCs running 24/7.
What It Cannot Establish Alone
- Whether the OpenSearch domain serves as a cold standby replica for cross-cluster disaster recovery failover.
- Whether periodic quarterly log analysis or compliance security scans execute queries exclusively outside the 14-day sampling window.
2. Telemetry & Evidence Requirements
ArthaOps operates strictly via Plane 1 (Read-Only Discovery). The following CloudFormation / IAM permissions and CloudWatch metrics are evaluated:
AWS::OpenSearch::DomainVerification Protocol: Tested against simulated OpenSearch 2-node cluster fixtures with SearchRate == 0 and IndexingRate == 0.
Validation Context: Validated in development and QA VPCs discovering dedicated Elasticsearch clusters deployed for evaluation projects and abandoned post-launch.
3. Reproducible AWS CLI Verification Recipe
Describe OpenSearch cluster topology, instance types, and storage configuration in ap-south-1.
# Describe OpenSearch cluster topology in ap-south-1
aws opensearch describe-domain \
--region ap-south-1 \
--domain-name dev-logging-cluster \
--query "DomainStatus.{Domain:DomainName,InstanceType:ClusterConfig.InstanceType,Count:ClusterConfig.InstanceCount,StorageGB:EBSOptions.VolumeSize,Engine:EngineVersion}" \
--output table---------------------------------------------------------------------------------------------------
| DescribeDomain |
+----------------------+--------------------+-----------------+--------------+--------------------+
| Domain | Engine | Count | InstanceType | StorageGB |
+----------------------+--------------------+-----------------+--------------+--------------------+
| dev-logging-cluster | OpenSearch_2.11 | 2 | m6g.large.search | 100 |
+----------------------+--------------------+-----------------+--------------+--------------------+💡 Cluster 'dev-logging-cluster' provisions 2 m6g.large.search nodes and 200 GB EBS gp3 storage. In dev/staging with zero search or indexing queries, this burns $0.158/hr per node continuously.
4. Transparent Economic Model
- Illustrative scenario based on a 2-node m6g.large.search cluster with 200 GB EBS gp3 storage in ap-south-1.
- 730 operational hours per standard calendar month at static ₹84.00/USD conversion.
- Cluster exhibits zero search queries and zero indexing requests across 14 consecutive days.
- Actual savings depend on node count, instance family, and dedicated master node topology.
- Automated hourly snapshot storage in S3 is free up to the size of the cluster.
5. False-Positive Scenarios & Operational Risks
Never delete or terminate cloud resources blindly. These validated architectural scenarios must be reviewed before initiating remediation:
Documented False-Positive Scenarios
- Warm Cross-Cluster Search DR Target: Remote OpenSearch cluster configured for cross-cluster replication awaiting failover.
- Infrequent Audit Forensic Investigations: Security clusters queried solely during incident response or quarterly penetration test retrospectives.
Blast Radius & Remediation Risks
- Application Connection Failure: Deleting a domain invalidates the OpenSearch endpoint URL. Applications attempting to connect will receive DNS resolution errors.
- Mitigation: Capture an automated manual S3 snapshot via OpenSearch snapshot API before decommissioning.
6. Remediation Procedure & Rollback Runbook
Follow this ordered sequence of verified AWS CLI actions to remediate the resource with complete rollback availability:
Trigger Manual Index Snapshot to S3
Create a manual snapshot across all cluster indices using OpenSearch REST API.
curl -X PUT "https://search-dev-logging-cluster.ap-south-1.es.amazonaws.com/_snapshot/my-s3-repository/pre-delete-backup?wait_for_completion=true"Delete the Idle OpenSearch Domain
Delete the domain via AWS CLI once snapshot completion is confirmed.
aws opensearch delete-domain --region ap-south-1 --domain-name dev-logging-clusterForensic Rollback Procedure
To restore, create a new OpenSearch domain with the same configuration via `aws opensearch create-domain` and restore indices from the S3 snapshot via `_snapshot/my-s3-repository/pre-delete-backup/_restore`. Cluster provisioning takes 15–25 minutes.
🔒 ArthaOps Assurance: ArthaOps requires snapshot confirmation and 14-day zero-traffic verification before proposing OpenSearch domain decommissioning.
The new cluster will receive a new domain endpoint URL unless an internal route53 private hosted zone CNAME was used.
How This Appears in the ArthaOps Control Plane
2-node m6g.large.search cluster has 0 indexing requests and 0 search queries for 21 consecutive days.
Test Your Infrastructure in 180 Seconds
Explore our zero-setup interactive sample report covering real Mumbai findings, or launch a 100% read-only agentless scan across your AWS environment.